For some while, Ruby on Rails can use YARN to manage its JavaScript dependencies. And now, NodeJS maintainers were so nice, that we have YARN available in Rawhide!
V.
-------- Přeposlaná zpráva -------- Předmět: Fedora rawhide compose report: 20180517.n.1 changes Datum: Fri, 18 May 2018 05:35:34 +0000 Od: Fedora Rawhide Report rawhide@fedoraproject.org Adresa pro odpověď: Development discussions related to Fedora devel@lists.fedoraproject.org Komu: devel@lists.fedoraproject.org
OLD: Fedora-Rawhide-20180516.n.0 NEW: Fedora-Rawhide-20180517.n.1
===== ADDED PACKAGES =====
Package: nodejs-yarn-1.6.0-1.fc29 Summary: Fast, reliable, and secure dependency management. RPMs: nodejs-yarn Size: 3.01 MiB
This is really nice! We may think about adding `yarn` support to nodejs openshift buider [1] then.
Presently it is hardcoded to `npm` [2]. But we can add some variable and use yarn when it is set. Like what they did in this blog [3][4].
[1] https://github.com/sclorg/s2i-nodejs-container [2] https://github.com/sclorg/s2i-nodejs-container/blob/master/8/s2i/bin/assembl... [3] https://developers.redhat.com/blog/2017/06/02/installing-node-js-dependencie... [4] https://github.com/bucharest-gold/centos7-s2i-nodejs/blob/master/s2i/assembl...
Vít Ondruch wrote on 05/21/18 11:26:
For some while, Ruby on Rails can use YARN to manage its JavaScript dependencies. And now, NodeJS maintainers were so nice, that we have YARN available in Rawhide!
V.
-------- Přeposlaná zpráva -------- Předmět: Fedora rawhide compose report: 20180517.n.1 changes Datum: Fri, 18 May 2018 05:35:34 +0000 Od: Fedora Rawhide Report rawhide@fedoraproject.org Adresa pro odpověď: Development discussions related to Fedora devel@lists.fedoraproject.org Komu: devel@lists.fedoraproject.org
OLD: Fedora-Rawhide-20180516.n.0 NEW: Fedora-Rawhide-20180517.n.1
===== ADDED PACKAGES =====
Package: nodejs-yarn-1.6.0-1.fc29 Summary: Fast, reliable, and secure dependency management. RPMs: nodejs-yarn Size: 3.01 MiB
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
On Mon, May 21, 2018 at 4:35 AM Aleksandar Kostadinov akostadi@redhat.com wrote:
This is really nice! We may think about adding `yarn` support to nodejs openshift buider [1] then.
Presently it is hardcoded to `npm` [2]. But we can add some variable and use yarn when it is set. Like what they did in this blog [3][4].
Please use the "yarnpkg" binary rather than "yarn" binary. Due to conflicts in the repository, "/usr/bin/yarn" is "/usr/bin/nodejs-yarn". But "/usr/bin/yarnpkg" has been preserved from upstream, so that should work.
Too bad, we're not talking about manual usage here but also projects likely have build scripts or something. Using aliases is IMO a no-go.
I see presently 2 other packages providing `yarn` executable:
$ sudo dnf whatprovides /usr/bin/yarn [sudo] password for avalon: Last metadata expiration check: 1:37:54 ago on Mon May 21 10:56:24 2018. cmdtest-0.30-1.fc27.noarch : Black-box testing for Unix command line
tools
Repo : fedora Matched from: Filename : /usr/bin/yarn
hadoop-yarn-2.7.3-6.fc27.noarch : Apache Hadoop YARN Repo : fedora Matched from: Filename : /usr/bin/yarn
IMO we should provide some alternatives mechanism so that `yarn` is whatever the user wants. We can't ask upstream packages to change to Fedora specific binary names. Or we can but we will be ignored.
If we don't handle `yarn` better, then users would likely just install `yarn` globally with `npm` and the distro package will not be used. Thus the exercise to maintain it would be mostly worthless.
Neal Gompa wrote on 05/21/18 12:03:
On Mon, May 21, 2018 at 4:35 AM Aleksandar Kostadinov akostadi@redhat.com wrote:
This is really nice! We may think about adding `yarn` support to nodejs openshift buider [1] then.
Presently it is hardcoded to `npm` [2]. But we can add some variable and use yarn when it is set. Like what they did in this blog [3][4].
Please use the "yarnpkg" binary rather than "yarn" binary. Due to conflicts in the repository, "/usr/bin/yarn" is "/usr/bin/nodejs-yarn". But "/usr/bin/yarnpkg" has been preserved from upstream, so that should work.
On Mon, May 21, 2018 at 5:39 AM Aleksandar Kostadinov akostadi@redhat.com wrote:
Too bad, we're not talking about manual usage here but also projects likely have build scripts or something. Using aliases is IMO a no-go.
I see presently 2 other packages providing `yarn` executable:
$ sudo dnf whatprovides /usr/bin/yarn [sudo] password for avalon: Last metadata expiration check: 1:37:54 ago on Mon May 21 10:56:24
2018.
cmdtest-0.30-1.fc27.noarch : Black-box testing for Unix command line
tools
Repo : fedora Matched from: Filename : /usr/bin/yarn
hadoop-yarn-2.7.3-6.fc27.noarch : Apache Hadoop YARN Repo : fedora Matched from: Filename : /usr/bin/yarn
IMO we should provide some alternatives mechanism so that `yarn` is whatever the user wants. We can't ask upstream packages to change to Fedora specific binary names. Or we can but we will be ignored.
If we don't handle `yarn` better, then users would likely just install `yarn` globally with `npm` and the distro package will not be used. Thus the exercise to maintain it would be mostly worthless.
Take it up with the maintainers of nodejs-yarn, cmdtest, and hadoop-yarn. I'd probably object to the usage of alternatives for this, since it makes no sense in this case (all three /usr/bin/yarn binaries do different things). If all three can be made to agree, then /usr/bin/yarn should probably go to nodejs-yarn, due to its well-known usage.
But I disagree on it being "worthless". People are increasingly using yarn data and preferring it over npm, so being able to support that in the distribution is very useful.
-- 真実はいつも一つ！/ Always, there's only one truth!
Neal Gompa wrote on 05/21/18 12:46:
On Mon, May 21, 2018 at 5:39 AM Aleksandar Kostadinov akostadi@redhat.com wrote:
Too bad, we're not talking about manual usage here but also projects likely have build scripts or something. Using aliases is IMO a no-go.
I see presently 2 other packages providing `yarn` executable:
> $ sudo dnf whatprovides /usr/bin/yarn > [sudo] password for avalon: > Last metadata expiration check: 1:37:54 ago on Mon May 21 10:56:24
> cmdtest-0.30-1.fc27.noarch : Black-box testing for Unix command linetools > Repo : fedora > Matched from: > Filename : /usr/bin/yarn > > hadoop-yarn-2.7.3-6.fc27.noarch : Apache Hadoop YARN > Repo : fedora > Matched from: > Filename : /usr/bin/yarn
IMO we should provide some alternatives mechanism so that `yarn` is whatever the user wants. We can't ask upstream packages to change to Fedora specific binary names. Or we can but we will be ignored.
If we don't handle `yarn` better, then users would likely just install `yarn` globally with `npm` and the distro package will not be used. Thus the exercise to maintain it would be mostly worthless.
Take it up with the maintainers of nodejs-yarn, cmdtest, and hadoop-yarn.
Got it.
I'd probably object to the usage of alternatives for this, since it makes no sense in this case (all three /usr/bin/yarn binaries do different
IMO it's a kind of alternative. Can we ensure that none upstream packages will have conflicting binary names? And don't think we must be an arbiter to upstream conflicting interests.
things). If all three can be made to agree, then /usr/bin/yarn should probably go to nodejs-yarn, due to its well-known usage.
I'd agree if you ask me but should we enforce something to users that can be configurable?
But I disagree on it being "worthless". People are increasingly using yarn data and preferring it over npm, so being able to support that in the distribution is very useful.
It is useful if it is accessible in a standard way. I think practice to diverge from upstream in incompatible ways needs to stop.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
On Mon, May 21, 2018 at 7:31 AM Aleksandar Kostadinov akostadi@redhat.com wrote:
Neal Gompa wrote on 05/21/18 12:46:
On Mon, May 21, 2018 at 5:39 AM Aleksandar Kostadinov <
akostadi@redhat.com>
wrote:
Too bad, we're not talking about manual usage here but also projects likely have build scripts or something. Using aliases is IMO a no-go.
I see presently 2 other packages providing `yarn` executable:
> $ sudo dnf whatprovides /usr/bin/yarn > [sudo] password for avalon: > Last metadata expiration check: 1:37:54 ago on Mon May 21
10:56:24
> cmdtest-0.30-1.fc27.noarch : Black-box testing for Unix command
line
tools > Repo : fedora > Matched from: > Filename : /usr/bin/yarn > > hadoop-yarn-2.7.3-6.fc27.noarch : Apache Hadoop YARN > Repo : fedora > Matched from: > Filename : /usr/bin/yarn
IMO we should provide some alternatives mechanism so that `yarn` is whatever the user wants. We can't ask upstream packages to change to Fedora specific binary names. Or we can but we will be ignored.
If we don't handle `yarn` better, then users would likely just install `yarn` globally with `npm` and the distro package will not be used.
Thus
the exercise to maintain it would be mostly worthless.
Take it up with the maintainers of nodejs-yarn, cmdtest, and
hadoop-yarn.
Got it.
I'd probably object to the usage of alternatives for this, since it
makes
no sense in this case (all three /usr/bin/yarn binaries do different
IMO it's a kind of alternative. Can we ensure that none upstream packages will have conflicting binary names? And don't think we must be an arbiter to upstream conflicting interests.
It's not even close to kind of an alternative. All three "yarn" binaries have completely different purposes.
Alternatives has a very specific definition: "A generic name in the filesystem is shared by all files providing interchangeable functionality."
It is not true in this case. Actually, this is why the standard yarn package provides both yarn and yarnpkg binaries. The latter never conflicts, while the former does in many cases.
things). If all three can be made to agree, then /usr/bin/yarn should probably go to nodejs-yarn, due to its well-known usage.
I'd agree if you ask me but should we enforce something to users that can be configurable?
But I disagree on it being "worthless". People are increasingly using
yarn
data and preferring it over npm, so being able to support that in the distribution is very useful.
It is useful if it is accessible in a standard way. I think practice to diverge from upstream in incompatible ways needs to stop.
It is available in one of the two standard executables provided by upstream. Would you prefer it available by neither?
Neal Gompa wrote on 05/21/18 14:38:
On Mon, May 21, 2018 at 7:31 AM Aleksandar Kostadinov akostadi@redhat.com wrote:
Neal Gompa wrote on 05/21/18 12:46:
On Mon, May 21, 2018 at 5:39 AM Aleksandar Kostadinov <
akostadi@redhat.com>
wrote:
Too bad, we're not talking about manual usage here but also projects likely have build scripts or something. Using aliases is IMO a no-go.
I see presently 2 other packages providing `yarn` executable:
> $ sudo dnf whatprovides /usr/bin/yarn > [sudo] password for avalon: > Last metadata expiration check: 1:37:54 ago on Mon May 2110:56:24
> cmdtest-0.30-1.fc27.noarch : Black-box testing for Unix commandline
tools > Repo : fedora > Matched from: > Filename : /usr/bin/yarn > > hadoop-yarn-2.7.3-6.fc27.noarch : Apache Hadoop YARN > Repo : fedora > Matched from: > Filename : /usr/bin/yarn
IMO we should provide some alternatives mechanism so that `yarn` is whatever the user wants. We can't ask upstream packages to change to Fedora specific binary names. Or we can but we will be ignored.
If we don't handle `yarn` better, then users would likely just install `yarn` globally with `npm` and the distro package will not be used.
Thus
the exercise to maintain it would be mostly worthless.
Take it up with the maintainers of nodejs-yarn, cmdtest, and
hadoop-yarn.
Got it.
I'd probably object to the usage of alternatives for this, since it
makes
no sense in this case (all three /usr/bin/yarn binaries do different
IMO it's a kind of alternative. Can we ensure that none upstream packages will have conflicting binary names? And don't think we must be an arbiter to upstream conflicting interests.
It's not even close to kind of an alternative. All three "yarn" binaries have completely different purposes.
Alternatives has a very specific definition: "A generic name in the filesystem is shared by all files providing interchangeable functionality."
I guess it can be used for both purposes. After all having some files possibly from different packages without a standard way to select which one wins makes less sense from user standpoint of view than providing an alternative.
It is not true in this case. Actually, this is why the standard yarn package provides both yarn and yarnpkg binaries. The latter never conflicts, while the former does in many cases.
So we provide both in our package. Ok, that's fair. I see for the first time that we support packages with conflicting file names. I thought this is forbidden at least in main repo.
things). If all three can be made to agree, then /usr/bin/yarn should probably go to nodejs-yarn, due to its well-known usage.
I'd agree if you ask me but should we enforce something to users that can be configurable?
But I disagree on it being "worthless". People are increasingly using
yarn
data and preferring it over npm, so being able to support that in the distribution is very useful.
It is useful if it is accessible in a standard way. I think practice to diverge from upstream in incompatible ways needs to stop.
It is available in one of the two standard executables provided by upstream. Would you prefer it available by neither?
If this name is also available upstream, then this is much more useful. I didn't know this. Only used `yarn` in the past. But now I see the other one available on my system as well. So it makes perfect sense to use `yarnpkg` in scripts.
Thanks.
ruby-sig@lists.fedoraproject.org
-
Aleksandar Kostadinov -
Neal Gompa -
Vít Ondruch