Open JanPokorny opened 3 months ago
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!
+yarn
is ambiguous. you either want: pkgx +classic.yarnpkg.com -- bash
or pkgx +yarnpkg.com -- bash
. the error message is definitely misleading.
@jhheider What's the purpose of having a separate classic.yarnpkg.com
? As opposed to simply having yarn@1
.
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.
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
@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:
brew
, apt
, scoop
) which keep only the newest version packaged for each (eg. python@3.9
on Brew is Python 3.9.19 and there is no easy way to go to eg. 3.9.18)asdf
, pip
, npm
) where a version range can be specified when installing a packageI 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.
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.
When using
pkgx +yarn -- command
, this happens:Furthermore to the error text being clearly wrong, the URL 404s.