Pkgx sometimes "forgets" to provide dependencies?

[gaggle]

I've twice in the past two weeks had the case where it seems like the pkgx environment loses track of a dependency. I've captured the output below, for this issue note I pull in Erlang and gnu utils:

$ cat .pkgx.yml
dependencies:
  erlang.org: =26.2.4
  elixir-lang.org: =1.16.2
  postgresql.org: =15.2.0
  github.com/bats-core/bats-core: =1.11.0
  gnu.org/bash: =5.2.21
  gnu.org/coreutils: =9.5.0
  gnu.org/grep: =3.11.0
  tcl-lang.org/expect: =5.45.4
$ pkgx --version
pkgx 1.1.6
$ cat ~/.zshenv | grep pkgx
# pkgx
source <(pkgx --shellcode) # docs.pkgx.sh/shellcode

Here pkgx is providing Erlang, as expected:

$ which erl
~/.pkgx/erlang.org/v26.2.4/bin/erl

But it's not providing stat:

$ which stat
/usr/bin/stat

But if I leave and come back stat does get pkgx provided:

$ cd ..
env -gnu.org/coreutils=9.5.0 -erlang.org=26.2.4 -elixir-lang.org=1.16.2 -postgresql.org=15.2.0 -github.com/bats-core/bats-core=1.11.0 -gnu.org/bash=5.2.21 -gnu.org/grep=3.11.0 -tcl-lang.org/expect=5.45.4 -git-scm.org
cd%                                                                       
$ cd perfect-elixir/
Assertion failed: pkgx: env is being duped
env +gnu.org/coreutils=9.5.0 +erlang.org=26.2.4 +elixir-lang.org=1.16.2 +postgresql.org=15.2.0 +github.com/bats-core/bats-core=1.11.0 +gnu.org/bash=5.2.21 +gnu.org/grep=3.11.0 +tcl-lang.org/expect=5.45.4 +git-scm.org
$ which stat
~/.pkgx/gnu.org/coreutils/v9.5.0/bin/stat

I haven't noticed what I do to cause this, but I'll try to look out for any patterns. Anyone have suggestions I can try?

[dosubot]

Hey there @gaggle! 👋 I'm Dosu, your friendly bot here to help with bugs, answer questions, and guide you on contributing while we wait for a human maintainer. Just wanted to let you know I'm diving into your issue about pkgx and its mysterious dependency behavior. Hang tight, I'll get back to you with some insights soon!

[gaggle]

Hmm. Now that I pay attention, it seems to happen when I start a new terminal that starts in the pkgx'd folder 🤔

Here I step into the folder as previous post, and it all works:

(btw the warn: parse failure stuff has just started appearing, I didn't do anything since last posting. I'll just ignore it for this issue)

$ cd perfect-elixir/
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
Assertion failed: pkgx: env is being duped
env +gnu.org/coreutils=9.5.0 +erlang.org=26.2.4 +elixir-lang.org=1.16.2 +postgresql.org=15.2.0 +github.com/bats-core/bats-core=1.11.0 +gnu.org/bash=5.2.21 +gnu.org/grep=3.11.0 +tcl-lang.org/expect=5.45.4 +git-scm.org
$ which stat
~/.pkgx/gnu.org/coreutils/v9.5.0/bin/stat

And then I open a new terminal, which I have configured for Warp to open in previous session's directory:

The new terminal immediately activates pkgx dev as expected, but it somehow doesn't have stat:

warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
warn: parse failure: github.com/oneapi-src/oneTBB
Assertion failed: pkgx: env is being duped
env +gnu.org/coreutils=9.5.0 +erlang.org=26.2.4 +elixir-lang.org=1.16.2 +postgresql.org=15.2.0 +github.com/bats-core/bats-core=1.11.0 +gnu.org/bash=5.2.21 +gnu.org/grep=3.11.0 +tcl-lang.org/expect=5.45.4 +git-scm.org

which stat
/usr/bin/stat

Since non-system tools are do get provided by pkgx I suppose my theory is pkgx activates, but then somehow gets clobbered by MacOS system tools which causes stat, expect, etc to revert back to system paths.

I'm still not sure if this is my system being messed up or if it is something rooted in pkgx.

[gaggle]

Minor update to say the warn: parse failure: github.com/oneapi-src/oneTBB appears to have gone with pkgx --sync. The underlying problem of opening a new terminal and some dependencies not being active remains though.

[mxcl]

Posibly fixed in 1.2.0 since we deal with the “dupe” situation which your logs talk about better.

[gaggle]

I've upgraded, but the same behavior is present:

$ pkgx --version
pkgx 1.2.1

$ cd testing-pkgx/
env +gnu.org/bash=5.2.21 +git-scm.org

$ cat .pkgx.yml
dependencies:
  gnu.org/bash: =5.2.21

$ which bash
.../.pkgx/gnu.org/bash/v5.2.21/bin/bash

So far so good!

But when I open a new tab (i.e. CMD-T) pkgx does not actually provide bash until I turn pkgx off and on again:

env +gnu.org/bash=5.2.21 +git-scm.org
$ which bash
/bin/bash

$ dev off && dev on
env -gnu.org/bash=5.2.21 -git-scm.org
env +gnu.org/bash=5.2.21 +git-scm.org

$ which bash
.../.pkgx/gnu.org/bash/v5.2.21/bin/bash

(my terminal is configured to start new tabs in current working directory)

I've run pkgx --sync and such but it doesn't change this behavior. I observe this in both the built-in Terminal.app and Warp terminal.

edit: Just to add -- my shell is default MacOS Zsh

[jhheider]

I've seen this with warp. I don't believe opening in a dev runs the relevant hook. cd; cd - might be a little lighter (and could possibly be in your .bashrc).

[gaggle]

Just to confirm, this is still happening on dev 1.5.0, in both MacOS's Terminal.app and Warp:

I first go to a directory with a devenv, where tar is loaded correctly:

$ cd project
+gnu.org/tar=1.35.0

$ which tar
~/.pkgx/gnu.org/tar/v1.35.0/bin/tar

Then I CMD-T to open new terminal that starts in that same directory, but now tar is not properly loaded until I toggle the devenv:

+gnu.org/tar=1.35.0

$ which tar
/usr/bin/tar

$ cd; cd -
-gnu.org/tar=1.35.0
+gnu.org/tar=1.35.0

$ which tar
~/.pkgx/gnu.org/tar/v1.35.0/bin/tar

$ dev --version
dev 1.5.0

Perhaps this is all by design, but in case it counts as fixable behaviour I wanted to keep this ticket up-to-date.

[mxcl]

this is not by design and is a bug. Its odd as I remember explicitly coding behavior to handle this. I haven't had tabs open in the same directory for a year or so though hence I haven't seen it.