Ability to run a different version inside a "dev" folder

[chmac]

I think according to #291 I should be able to run pkgx +nodejs.org@^22 in a folder which already has a pkgx environment setup via dev and the shell integration. But that doesn't work. Instead I get:

× unexpected error cannot intersect: @12.22.12 && @22.12.0
│ Error: cannot intersect: @12.22.12 && @22.12.0

Full disclosure, my version specifier was actually 22.12.0 because ^22 creates a different error.

[jhheider]

pkgx +nodejs.org@^22 should be pkgx +nodejs.org^22. I suspect it's the @ which is messing things up.

[chmac]

@jhheider Thanks, that mistake, using both @ and ^, got me into all kinds of trouble!

But, nonetheless, when add "pkgx": "node^12" to package.json and run dev, I get node 12, but if I then run pkgx +node^22 node --version then I get the same as above, the cannot intersect error. Maybe there's something I'm missing here, or another mistake I'm making. My hope was to be able to run specific commands in a given directory, while at the same time having dev automatically make the default version available.

[jhheider]

I believe you'll have to turn dev off to use a different version. Or you can run it directly by path, if all the library linkages work. It's because the dev environment is meant to apply to all processes in that directory.

[chmac]

Gotcha. Can I switch this issue into a feature request then? My wish would be that running pkgx +node^23 overrides whatever is loaded by dev. That seems intuitive to me, in that I can always override the default environment explicitly.

[jhheider]

Sure. The idea is a little complicated. Like if you switched a library but still expected the things in the devenv to be runnable. But that might not be any less intuitive that what you're experiencing.

[jhheider]

PKGX_POWDER= pkgx node~12 --version seems to work:

jacob@illithid foo % dev
env +nodejs.org@20.0.0
jacob@illithid foo % pkgx node~12 --version
× unexpected error cannot intersect: @20.0.0 && ^12
│ Error: cannot intersect: @20.0.0 && ^12
│     at Module.intersect (https://deno.land/x/libpkgx@v0.17.0/src/utils/semver.ts:384:30)
│     at condense (https://deno.land/x/libpkgx@v0.17.0/src/plumbing/hydrate.ts:95:33)
│     at hydrate (https://deno.land/x/libpkgx@v0.17.0/src/plumbing/hydrate.ts:13:15)
│     at file:///Users/builder/actions-runner/_work/pantry/pantry/builds/pkgx.sh-1.1.6/src/prefab/install.ts:10:60
│     at failsafe (file:///Users/builder/actions-runner/_work/pantry/pantry/builds/pkgx.sh-1.1.6/src/prefab/failsafe.ts:5:18)
│     at default (file:///Users/builder/actions-runner/_work/pantry/pantry/builds/pkgx.sh-1.1.6/src/prefab/install.ts:10:47)
│     at eventLoopTick (ext:core/01_core.js:182:7)
│     at async default (file:///Users/builder/actions-runner/_work/pantry/pantry/builds/pkgx.sh-1.1.6/src/modes/x.ts:30:18)
│     at async default (file:///Users/builder/actions-runner/_work/pantry/pantry/builds/pkgx.sh-1.1.6/src/app.ts:48:11)
│     at async file:///Users/builder/actions-runner/_work/pantry/pantry/builds/pkgx.sh-1.1.6/entrypoint.ts:59:3
╰─➤ https://github.com/pkgxdev/pkgx/issues/new
jacob@illithid foo % PKGX_POWDER= pkgx node~12 --version
v12.22.12

I assume there's a bunch of things that could go wrong, with mismatching libraries and what have you, but if it works, it might be a sufficient workaround. You could use a tool like just or xc or a shell script to wrap the invocation to make it easier, i.e.:

jacob@illithid foo % just node12 --version
v12.22.12
jacob@illithid foo % cat justfile
node12 +ARGS:
  @PKGX_POWDER= pkgx node~12 {{ARGS}}

[chmac]

Another champion workaround. Adding the PKGX_POWDER env var empty works. Again, it's a totally adequate workaround. Thanks.

I'd be interested in opening a feature request to have pkgx +foo "just work" inside a folder which is already running dev, if that's something that makes sense for the project. Happy to leave this issue open for that, or feel free to close it if it doesn't fit. My personal challenge has been solved, thank you.

[jhheider]

Definitely leave it open. It'll come up again, and it's worth considering. If nothing else, the error is frustrating.