Can't use yarn in context of another command

[JanPokorny]

When using pkgx +yarn -- command, this happens:

❯ pkgx +yarn -- bash
× multiple projects provide: yarn
│ pls be more specific:
│ 
│     pkgx +classic.yarnpkg.com +yarn -- bash 
│     pkgx +yarnpkg.com +yarn -- bash 
│ 
╰─➤ https://docs.pkgx.sh/help/ambiguous-pkgspec

❯ pkgx +classic.yarnpkg.com +yarn -- bash
× multiple projects provide: yarn
│ pls be more specific:
│ 
│     pkgx +classic.yarnpkg.com +classic.yarnpkg.com +yarn -- bash 
│     pkgx +yarnpkg.com +classic.yarnpkg.com +yarn -- bash 
│ 
╰─➤ https://docs.pkgx.sh/help/ambiguous-pkgspec

❯ pkgx +yarnpkg.com +yarn -- bash
× multiple projects provide: yarn
│ pls be more specific:
│ 
│     pkgx +classic.yarnpkg.com +yarnpkg.com +yarn -- bash 
│     pkgx +yarnpkg.com +yarnpkg.com +yarn -- bash 
│ 
╰─➤ https://docs.pkgx.sh/help/ambiguous-pkgspec

Furthermore to the error text being clearly wrong, the URL 404s.

[dosubot]

Hello @JanPokorny! 🤖✨ I'm Dosu, a bot here to assist you with bugs, answer your questions, and guide you on contributing while we wait for a human maintainer to join in. I'm all about helping out, so let's tackle this issue together. I'm diving into your problem right now and will follow up with a solution shortly!

[jhheider]

+yarn is ambiguous. you either want: pkgx +classic.yarnpkg.com -- bash or pkgx +yarnpkg.com -- bash. the error message is definitely misleading.

[JanPokorny]

@jhheider What's the purpose of having a separate classic.yarnpkg.com? As opposed to simply having yarn@1.

[jhheider]

We debated the correct way to handle it. Basically yarnv1 and berry are pretty different and both under active development. Tt was decided that breaking them up was the correct path forward. A similar choice was made, though for slightly different reasons, with pcre.org and pcre.org/v2. It's possible we should have done the same thing with openssl v1.1 and v3, and that has created some but not a lot of issues.

[dosubot]

It appears there are no specific actions to run or outputs to integrate into a response based on the given instructions. Therefore, I'll synthesize a response based on the conversation provided.

---

Hello @JanPokorny,

Thank you for bringing up your concerns regarding the use of yarn in the context of another command and the confusion around classic.yarnpkg.com versus yarnpkg.com. It seems there's been a bit of confusion due to the ambiguous nature of the +yarn specifier and the misleading error messages you've encountered.

To clarify, the separation into classic.yarnpkg.com and yarnpkg.com was a deliberate decision to accommodate the significant differences between Yarn v1 (Classic) and Yarn Berry (v2 and beyond). Both versions are under active development but cater to different use cases and have distinct features. This separation is similar to how other projects, like PCRE, have handled major version differences.

For your specific case, when you want to use Yarn in the context of another command with pkgx, you should specify either pkgx +classic.yarnpkg.com -- bash or pkgx +yarnpkg.com -- bash depending on the version of Yarn you intend to use. This should help avoid the ambiguity and the errors you've been facing.

We acknowledge that the error message provided was misleading and the documentation link was not working. We'll look into improving the error messages and ensuring that the documentation is accessible to prevent such confusion in the future.

If you have any more questions or need further clarification, feel free to ask. We're here to help!

Best,
Dosu

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[JanPokorny]

@jhheider I see, thanks for clarifying. As a feedback from someone just starting with / evaluating pkgx, this is a bit confusing design. Other package managers either have:

• per-version packages for cases where this is appropriate (eg. brew, apt, scoop) which keep only the newest version packaged for each (eg. [email protected] on Brew is Python 3.9.19 and there is no easy way to go to eg. 3.9.18)
• full version support (eg. asdf, pip, npm) where a version range can be specified when installing a package

I initially thought that pkgx falls into the second category (since you can append @version to any package you wish, including minor versions), but the Yarn split really seems like the first category, so both approaches are combined here in a sort of confusing way. As a user, I would expect pkgx yarn to just work similar to pkgx python, without caring that some past versions are packaged differently.

This is just my UX/DX feedback though. I understand that it might be hard to do this differently with the current tech. The concrete issue here is that the error message is unhelpful.

[jhheider]

No, you're not wrong that it's somewhat related to the first idea. pkgx is absolutely the second style; we've just taken the position (supported by the separate GitHub repos), that those two yarn projects are different projects.

You've hit one of a very small number of case (the three mentioned I believe) that suffer from that. The error message is trying to help you, but it's a complicated answer.