Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looks like only tea can find packages #156

Open
svallory opened this issue May 24, 2023 · 5 comments
Open

Looks like only tea can find packages #156

svallory opened this issue May 24, 2023 · 5 comments

Comments

@svallory
Copy link

svallory commented May 24, 2023

I ran into an issue trying to run a yarn task. I got a "node not found" error. Then I went to check on the terminal and got this... which and whereis cannot find node, but the magic is happening for tea.

image

I have two questions:

How can I automatically add new pantries to my path?
See: https://docs.tea.xyz/appendix/faq#i-need-a-tool-in-path-aka-brew-install

How can I change the version I want to use in the command line? (i.e. no dev env)

@mxcl
Copy link
Member

mxcl commented May 24, 2023

which doesn't work

yes, we basically document this. Magic works above the shell, so which cannot see commands. This is sorta a “feature” though we have considered reimplementing which so it can say “tea would find this* when you type it. We may still do so.

How can I automatically add new pantries to my path?

At some point we'll add a post install hook, or someone can make a tea install command that is its own pkg (provides tea-install). But yes for now you can symlink.

How can I change the version I want to use in the command line? (i.e. no dev env)

$ node^19 --version
v19.9.0

$ node^18 --version
v18.15.0

@mxcl
Copy link
Member

mxcl commented May 24, 2023

If you need other tools to find tea provided tooling there's a few ways:

  1. create a env with tea +nodejs.org sh
  2. execute the other commands with the env tea +foo.com CMD ARGS
  3. inject tea’s magic into a script (currently you have to edit the script to do this)

probs there are more.

@svallory
Copy link
Author

Thank you for the quick reply, @mxcl :)

I think Tea's slogan "the next generation package manager" threw me off :/ I was already thinking of replacing brew + asdf/nvm for many of the packages I use at least. But not to worry, I found a reasonable solution for the time being on that page I linked.

About the changing versions though, calling node^19 isn't the same as changing the node version available on the environment. Many, many scripts and npm packages will break if I tried that (yarn run build wasn't working btw. It couldn't find node but node --version was running ok, which was very confusing for a while)

The only solution I have for now is to use a script to unlink and relink the version I want to use from tea's dir to /usr/local/bin

we have considered reimplementing which so it can say “tea would find this* when you type it. We may still do so.

I would NOT recommend that. Nobody would expect tea was doing it. And I believe you guys will run into a LOT of issues if you do. What would happen with nologin shells, other users, on each linux distro plus OS X?

I said I wanted a solution outside of tea's developer environments but I should have been more specific, I wanted to know how to install a global package using tea. Actually, since I didn't pick were packages should go, I assumed they where global (for my user).

Finally, I think tea install should be done by the core team, even if it only manages symlinks for now. Here's why: the cost of implementing a script that manages symlinks for a core member (and keeping it up-to-date) is very low if compared to an external developer. What I've seen happen in these cases is that the package works well initially and overtime changes happen to the core software, the package doesn't get updated and someone has to create tea-install2

I can contribute the initial sh script in a PR if you guys want it. If you do, my suggestion would be to add 2 commands:

tea install [--(global|system)] [--use=false] PANTRY
tea use PANTRY VERSION 

@mxcl
Copy link
Member

mxcl commented May 25, 2023

I think Tea's slogan "the next generation package manager" threw me off :/

It wouldn't be next generation if it worked the same.

I was already thinking of replacing brew + asdf/nvm for many of the packages I use at least

We certainly would like you to be able to. We're very new so maybe don't have complete feature parity, but we are happy to add things.

About the changing versions though, calling node^19 isn't the same as changing the node version available on the environment.

Oh ok. You said you didn't want to change the dev-env. Sorry for my confusion.

You can open a new temporary shell: tea +nodejs.org^19 sh for such things.

I would NOT recommend that. Nobody would expect tea was doing it. And I believe you guys will run into a LOT of issues if you do. What would happen with nologin shells, other users, on each linux distro plus OS X?

it would be a shell function so nothing but the user typing into the terminal would see it, and the output would be obviously from tea. Maybe you're right that it's a bad idea, like I said, we're only considering it.

Finally, I think tea install should be done by the core team, even if it only manages symlinks for now. Here's why: the cost of implementing a script that manages symlinks for a core member (and keeping it up-to-date) is very low if compared to an external developer.

Maybe you're right. Maybe I'll get to it one day.

What I've seen happen in these cases is that the package works well initially and overtime changes happen to the core software, the package doesn't get updated and someone has to create tea-install2

well we control the registry so we would just delete install in such a case. Not to mention I wouldn't personally let the thing get broken since it would rapidly be considered core functionality.

@svallory
Copy link
Author

It wouldn't be next generation if it worked the same.

I was referring to the "package manager" part 😅 Sorry if that sounded like an attack. I do think tea is next-gen. My point is that we have a reference in regard to what the term "package manager" means and that generates certain expectations.

In the case of tea, since no scope was declared (node, rust, etc....) I assumed it was a system package manager, that's all. As it is right now I think a dev env manager would be a better metaphor.

well we control the registry so we would just delete install in such a case. Not to mention I wouldn't personally let the thing get broken since it would rapidly be considered core functionality.

Ohhhh that's very good to hear! I'm in the middle of hustling a new startup, but I'll check back when I have some time and contribute it if it hasn't been done yet by then

Thank you for all the support!

(btw, feel free to close this)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants