can not overwrite dependencies of pkgx packages even if the new one is acceptable
j1philli opened this issue · comments
this way I am trying to remove the first version but it won't remove because it is a dep of another pkgx package
pkgx.yaml won't over ride what gets installed even though it is in the accepted range
I'm confused, is your report:
env -python.orgdoesn’t work- that you are expecting a different python version to 3.11.x—if so, which?
Both. As the title suggests, pkgx packages that are dependencies of other pkgx packages can not be changed even if they fall into accepted version range.
Python is a dependency of poetry so pkgx install python for us, it installs the latest. However I need it to a different version.
I try to specify in pkgx.yaml but it does not change to that version even though it is in the allowed version for poetry.
I also try to env -python.org so that I can remove the current version to install the one I need but it does not work for packages that are dependencies.
Try this:
$ dev
× no env
$ env +python-poetry.org
✓ ~/.pkgx/python-poetry.org/v1.6.1
$ python --version
Python 3.11.6
$ env +python~3.10
$ python --version
Python 3.10.13Interesting.
So I needed 3.11.0 so running env +python@3.11.0 overwrote 3.11.6 as you suggested! Thanks! It does not save this though, so exiting and coming back to the dev environment has 3.11.6 again.
Doing as you say for downgrading minor version results in:
env +python~3.10
resolving graph…× unexpected error cannot intersect: ~3.11 && ~3.10
│ Error: cannot intersect: ~3.11 && ~3.10
│ at Module.intersect (https://deno.land/x/libpkgx@v0.14.1/src/utils/semver.ts:382:30)
│ at condense (https://deno.land/x/libpkgx@v0.14.1/src/plumbing/hydrate.ts:78:33)
│ at hydrate (https://deno.land/x/libpkgx@v0.14.1/src/plumbing/hydrate.ts:13:15)
│ at file:///Users/builder/actions-runner/_work/pkgx/pkgx/src/prefab/install.ts:9:58
│ at failsafe (file:///Users/builder/actions-runner/_work/pkgx/pkgx/src/prefab/failsafe.ts:5:18)
│ at default (file:///Users/builder/actions-runner/_work/pkgx/pkgx/src/prefab/install.ts:9:45)
│ at eventLoopTick (ext:core/01_core.js:183:11)
│ at async default (file:///Users/builder/actions-runner/_work/pkgx/pkgx/src/modes/internal.use.ts:16:20)
│ at async default (file:///Users/builder/actions-runner/_work/pkgx/pkgx/src/app.ts:57:20)
│ at async file:///Users/builder/actions-runner/_work/pkgx/pkgx/entrypoint.ts:59:3
╰─➤ https://github.com/pkgxdev/pkgx/issues/new
Is that after adding python=3.11.0? I wouldn't expect it to work then.
No that is with 3.11.6. I do however have 3.11 defined in a pkgx.yaml though
Ah, well, that would be the conflict then. Note that the operators are slightly different. I believe we treat @ as ~, as that's the most likely expectation:
$ pkgx +python@3.11 python --version
Python 3.11.6
$ pkgx +python~3.11 python --version
Python 3.11.6
$ pkgx +python@3.11.0 python --version
✓ ~/.pkgx/python.org/v3.11.0
Python 3.11.0
$ pkgx +python^3.11 python --version
Python 3.12.0Ahh interesting. Thanks
Try this:
$ dev × no env $ env +python-poetry.org ✓ ~/.pkgx/python-poetry.org/v1.6.1 $ python --version Python 3.11.6 $ env +python~3.10 $ python --version Python 3.10.13
Is the env +foo or specifying it in the pkgx.yaml just adding it to environment and leaving the version installed for dependency that poetry asks for?
env +foo adds it to the currently active environment, if a suitable version can be resolved against the existing constraints. poetry lists:
dependencies:
python.org: '>=3<3.12'so, env +python^2 or env +python\>3.13 will fail, if poetry is loaded in the environment.
Okay so it doesn't make both version available. Thanks
Okay so it doesn't make both version available. Thanks
We possibly should allow this, it doesn’t exactly hurt. But needs thought. Currently deps can only be resolved to a single version in a constraint graph.
I believe we treat @ as
~
@ is complex.
@3→^3@3.1→~3.1@3.1.2→>=3.1.2<3.1.3@3.1.2.3→>=3.1.2.3<3.1.3.4- etc.
I think this is in the docs.
We possibly should allow this, it doesn’t exactly hurt. But needs thought. Currently deps can only be resolved to a single version in a constraint graph.
No Python only wants one in an environment at a time. I was just confirming that it wasn't adding both.
however you can install multiple pythons alongside each other. I wonder if because that is true we should allow environments with multiple pythons? Food for thought.
however you can install multiple pythons alongside each other. I wonder if because that is true we should allow environments with multiple pythons? Food for thought.
i vote "one environment should use a unified python (or call pkgx +python@version python foo for esoteric needs)."
@jhheider is right
Yeah that sounds super pkgxish.