pkgx
pkgx copied to clipboard
pkgxdev
v* not working?
What is the purpose of v*? I assumed tea would use it to choose which version to run, but it looks like it isn't doing that. Maybe this is a bug?
> ls -al /opt/tea/python.org
total 0
drwxr-xr-x 8 u0076374 wheel 256 Nov 17 18:43 .
drwxr-xr-x 30 u0076374 wheel 960 Nov 16 23:55 ..
lrwxr-xr-x 1 u0076374 wheel 7 Nov 17 18:43 v* -> v3.10.8
lrwxr-xr-x 1 u0076374 wheel 7 Nov 17 18:43 v3 -> v3.10.8
lrwxr-xr-x 1 u0076374 wheel 7 Nov 17 18:39 v3.10 -> v3.10.8
drwxr-xr-x 6 u0076374 wheel 192 Oct 19 11:16 v3.10.8
lrwxr-xr-x 1 u0076374 wheel 7 Nov 16 22:58 v3.11 -> v3.11.0
drwxr-xr-x 6 u0076374 wheel 192 Oct 29 17:31 v3.11.0
> tea -X python --version
Python 3.11.0
> tea +python.org python --version
Python 3.11.0
v* should work like semver *, which is any version. It should be linked to the highest installed version, much as v0 is the highest 0.x.y version, etc.
From your state, it looks like it links the last installed satisfying version. That's less intuitive to me, but perhaps as @mxcl intends.
I assumed the symlinks would activate or deactivate a version, kind of like how it works in the filesystem elsewhere, but in retrospect, it won't work without calling it with tea anyway. So I'm not sure what its purpose really is since tea's logic is controlled by the semvar file.
One example is when re-writing library paths in compiled software, our compilation code "simplifies" the version path for RPATH lookup to e.g. $TEA_PREFIX/zlib.net/v1/lib/libz.so so any installed v1 zlib is locabale, if allowed by the package description. I agree that the consumers of the packages aren't likely to need the symlinks, unless they're creating outside dependencies on tea installations.
No it should link the biggest version. If not it's a bug. As you say this is due to semver spec saying * is any version (usually the latest) so we went with “always the latest” for predictability.
v* is mostly so you can as a user symlink to the newest version.
I know why this doesn't make sense to me. I can't think why an end user would link to anything in that directory. End users can't run the stuff in there without using tea because they need tea to set up the venv. The only thing I can think of is that they'd link to man pages or something like that. And that's a whole different discussion I think...
Actually I am linking to one thing, tea.xyz/v*/bin/tea. But it's the only thing that can be run without tea.
I use ln -s ~/.tea/deno.land/v*/bin/deno /usr/local/bin/deno personally.
as with brew I designed tea to have utility outside the tool itself.
all tea executables can be run without a venv, by design. Though this only works for the executables.
This is the case because we correctly set the rpaths. Now inside the venv things are more specific since we can set the dynamic library link path to specific versions of things. But that isn't so important for general sysops.
Hm. I didn't know the bin's were usable without tea.
When you explained this I had an idea. I'm not sure this makes a lot of sense, but the idea that occurred to me was to make static files that do what tea does and store them in the version directories. For example, ~/.tea/curl.se/v7.86.0/env.sh. And then add it via the shell's source command: . ~/.tea/curl.se/v7.86.0/env.sh.
Anyway, it was just a thought. I'm not sure you'd want to add env.sh because it breaks the app's sandbox. I'm not asking for the feature because I won't use it. But I thought I'd mention it. Some people may rather source a file then run a binary to get the environment set up.
I'll close this but I still think people may make the same guess that I did, that by changing the symlinks they're changing what tea will do. But now I see that tea has its own way of specifying the version, so the way it's set up does make sense.
Like we could, but is it really better than . $(tea -d +foo.com) which is the same.
Oh, you already have it! I should've read all the options! Yeah, this is cool.