Feature request: parse argv[0] and do the same with it as -X arg

[magnusviri]

I'd like to ln -s tea wget and have tea notice that argv[0] is "wget" and not "tea" and use argv[0] as the parameter of -X.

I'd also like to be able to version this so that I can have a 3.10 and a 3.11 python symlink. I've been trying to think of how to easily do this and here's what I came up with. Create something like "$TEA_PREFIX/python.org/v3.11.0/bin/tea-helper" and then I can link to that and it will notice what folder it is in and set up the environment and run the correct binary. I'm not sure that will work because it kind of breaks the package's sandbox. This doesn't break the sandbox but isn't as nice IMO "$TEA_PREFIX/tea.xyz/secretsauce/python.org/v3.11.0/tea-helper".

Everything else I think of requires passing arguments, which makes the symlink not work. I don't want to use the command_not_found handlers because then which doesn't work. I'd really rather not use shell aliases because then you have to configure each shell. A symlink works for every shell.

I don't want stub files. I think this is better than lots of launcher scripts (edit to add, that script of mine breaks tea updates, I'm not sure why yet, but it shouldn't really matter because I need to get rid of it). But I really would like to symlink directly to tea or to a tea-helper for version control.

Also, if one goes the symlink route, it would be beneficial to have a tool that looks for symlinks to tea and allow the user to quickly remove or archive them. And it would be cool to have a way to automatically create the symlinks too.

[magnusviri]

I am willing to work on this feature request if you're patient with me.

[jhheider]

This mirrors npm's idea of a -g|--global install, and would be a useful feature to an install command.

[magnusviri]

Yeah, I always use the global install options. I guess that's why I'm so focused on this.

[mxcl]

oh interesting. I already coded it so tea_foo runs foo (recent addition), but yeah, we could (also†) do what you suggest. This is a very neat idea. Also the version idea is splendid.

Yeah, let’s do it. Let us know if you need help! Here or discord.

And yes as @jhheider says, tea/cmd will make it possible to do global installs. But quite possibly this is a way better way to do that.

† some people will never like not having the tea_ prefix

[magnusviri]

FYI: I noticed that this line is checking to see if arg0 is "deno". If you are already linking deno to tea, then if I make this change then the behavior will change, and whatever you are doing will break.

[mxcl]

So… arg0 is deno when we are running from source, which notably includes all the times are running tests.

In other words, we do need to “be” deno. But in that case arg0 is not a symlink so that might help you.

[magnusviri]

Ok, so the solution is to check arg0 and see if it's actually a symlink. After following the symlink, if it's another symlink with either a version in the path or name or something, that can enable that stuff. I'm not sure what the best thing is.

curl -> curl@version curl@version -> /path/to/tea

or

curl@version -> curl curl -> /path/to/tea

When I'm off work later today I'll start reading the Deno docs about stat'ing files and work on this again.

[mxcl]

I think it’s as simple as:

• if foo is a symlink to tea then become tea -X foo
• if tea_foo is a symlink to tea then become tea -X foo
• if foo is not a symlink, ignore

[mxcl]

Possibly we should drop tea_foo but I don’t see any harm, it's a very small test matrix addition with no UI/UX overhead.

[magnusviri]

I don't see why we should drop tea_foo. Seems like a good idea to me.

[magnusviri]

I've been trying to think of how to do the symlink versioning and this is what I've come up with. If a file is a symlink, then read the link to see what it links to. If it links to the same name followed by a version string, then it can add that version string to the pkg dictionary. This is what the symlinks would look like. They don't have to be in the same directory.

python -> python=3.10 python=3.10 -> /path/to/tea

The symlink with the version could be any pattern supported by tea, like python^3.0.

The main code change has to be in app.X.ts line 37. The constraint would need to be changed to be something besides *. My question is do you want to try to parse the version in another file like utils/pkg.ts, hooks/useFlags.ts, or do you want put it in app.X.ts?

If I were to decide what to do, if I were going to do it quick I'd just copy the logic from pkg.ts to app.X.ts. If I were going to do it "right", I'd probably import pkg.ts in app.X.ts and I'd move the version parsing out of the parse function in pkg.ts into a function that I could call inside of app.X.ts.

I'm not a software developer and I've never worked on someone else's project like this. Well, ok, I did once and my pull requests were ignored because I changed too much. So I'm trying to be timid about my suggestions and everything. And I'll wait until I get some word on what you guys would want, and even if you want this feature at all.

[jhheider]

The way to make a smallest change set is encapsulation. So, as you suggested, collecting all the parsing in one place makes it easiest to review, and will result in the most consistency throughout the code base. Whether that's in a util, a hook, or somewhere else, it should be easy to relocate if it seems natural somewhere else, so I wouldn't worry about that quite as much. Just from a first think, I'd probably start with it close to where parsePackageRequirements lives.

[mxcl]

This is live. Reopen if I'm mistaken.