Re: FLAVORS for Ruby
Le 16/10/2019 à 09:02, David Demelier a écrit : Le 15/10/2019 à 18:41, Steve Wills a écrit : I disagree with the idea that we can have simply one version of Ruby in ports. Look at all the work it takes to move an app like GitLab to a new version of Ruby: https://gitlab.com/gitlab-org/gitlab-foss/issues/41825 https://gitlab.com/gitlab-org/gitlab-foss/issues/57323 I see no reason to think Ruby 2.7 will be any different. So Ruby team is lying with their versioning promise? So they say to follow semantic versioning while it's not [0] MINOR: increased every christmas, may be API incompatible Definitely not what semantic versioning defines. I finally understand why other languages gained popularity over it ;) [0]: https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/ -- Regards ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
Le 15/10/2019 à 18:41, Steve Wills a écrit : I disagree with the idea that we can have simply one version of Ruby in ports. Look at all the work it takes to move an app like GitLab to a new version of Ruby: https://gitlab.com/gitlab-org/gitlab-foss/issues/41825 https://gitlab.com/gitlab-org/gitlab-foss/issues/57323 I see no reason to think Ruby 2.7 will be any different. So Ruby team is lying with their versioning promise? -- David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
Le 14/10/2019 à 18:37, Koichiro Iwao a écrit : On Tue, Sep 17, 2019 at 07:34:27AM -0400, Steve Wills wrote: Hi, On 9/17/19 2:40 AM, Mathieu Arnold wrote: What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? The answer cannot be "because it should be fun" or "there is no reason there should not be". Give us a real reason about why it would be required. We have multiple versions of Ruby, we should provide the gems for each version. Right now, there is no way for users of Ruby 2.4 to install gem packages except to change the default ruby and then build their own packages. We want people to have fewer reasons to build their own packages, not more. We keep the latest Ruby as not default because it tends to have more bugs and gems lag, and the older version of Ruby is available because some gems tend to lag really badly. So, users do have legitimate reasons for using the non-default versions of Ruby. Also, upstream supports latest and two versions back. It wasn't until Ruby 2.6 was out that GitLab even supported 2.5, to give just one example. So, we have those versions of Ruby, and they should be usable, and that includes installing gems via pkg. There's the point that maybe we should only package gems that are needed by other things, which I can understand, but don't know if I necessarily agree with, because then you have users confused on what the "right" way to install a gem is. "Oh, this one is packaged because something else in ports needs it, so use the pkg, but this other one isn't packaged, so you have to use gem." And I'd think the same applies to python modules or perl modules, etc. One could ask, why not provide flavors for all versions of python, that is, 3.5, 3.6 and 3.7, along with the 2.7 ones as well, but to me that doesn't seem quite necessary because the compatibility is better there, as far as I can tell. But, I wouldn't be opposed to it personally, if someone did make the argument in favor of it. Same with Perl and especially things that depend on Java. But that's all beside the point, really. Steve Hello again everyone, I'm sorry I cannot express my thoughts correctly in English and I clould not explain why flavors for Ruby required but swills explained far better than me. Based on his explanation, will it be a valid reason to introduce flavors on Ruby ports? Ruby use semantic versioning since version 2.1.0, unless there is Ruby 3 version release there is no reason to have flavors in FreeBSD for Ruby. Also, I don't even understand why there is several Ruby version in the ports tree since Ruby 2.6 is (as guaranteed by semantic versioning) retro compatible with 2.5, 2.4 and so on. Ports ruby24, ruby25 should be deleted. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Tue, Sep 17, 2019 at 07:34:27AM -0400, Steve Wills wrote: > Hi, > > On 9/17/19 2:40 AM, Mathieu Arnold wrote: > > > > What we are all trying to say is that adding flavors for ruby will have > > a big impact on build time and ressources required for building. > > > > If all you want is to have ruby flavors for the kicks of it, then I am > > glad to tell you that no, it will not be done. > > > > Now, the question is, why would someone need to have ruby flavors? > > > > The answer cannot be "because it should be fun" or "there is no reason > > there should not be". > > > > Give us a real reason about why it would be required. > > > > We have multiple versions of Ruby, we should provide the gems for each > version. Right now, there is no way for users of Ruby 2.4 to install gem > packages except to change the default ruby and then build their own > packages. We want people to have fewer reasons to build their own packages, > not more. > > We keep the latest Ruby as not default because it tends to have more bugs > and gems lag, and the older version of Ruby is available because some gems > tend to lag really badly. So, users do have legitimate reasons for using the > non-default versions of Ruby. Also, upstream supports latest and two > versions back. > > It wasn't until Ruby 2.6 was out that GitLab even supported 2.5, to give > just one example. > > So, we have those versions of Ruby, and they should be usable, and that > includes installing gems via pkg. > > There's the point that maybe we should only package gems that are needed by > other things, which I can understand, but don't know if I necessarily agree > with, because then you have users confused on what the "right" way to > install a gem is. "Oh, this one is packaged because something else in ports > needs it, so use the pkg, but this other one isn't packaged, so you have to > use gem." > > And I'd think the same applies to python modules or perl modules, etc. One > could ask, why not provide flavors for all versions of python, that is, 3.5, > 3.6 and 3.7, along with the 2.7 ones as well, but to me that doesn't seem > quite necessary because the compatibility is better there, as far as I can > tell. But, I wouldn't be opposed to it personally, if someone did make the > argument in favor of it. Same with Perl and especially things that depend on > Java. > > But that's all beside the point, really. > > Steve Hello again everyone, I'm sorry I cannot express my thoughts correctly in English and I clould not explain why flavors for Ruby required but swills explained far better than me. Based on his explanation, will it be a valid reason to introduce flavors on Ruby ports? -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
Le 17/09/2019 à 08:40, Mathieu Arnold a écrit : What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? I second this. Ruby follows semantic versioning since 2.1.0 so there is no need to have flavors until they do a major release that breaks the compatibility. -- David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Tue, Sep 17, 2019 at 05:29:06PM +1000, Dewayne Geraghty wrote: > Bottom line: flavors came into being to satisfy specific needs. Python 2 > underwent substantial changes during the upgrade to python 3, to the extent > that many (most) python applications would cease to function. Similarly > php5 to php7. Without flavours the user-base would've been severly > impacted during the upgrade transition where some fraction of their > applications would fail. Flavours, though I didn't appreciate it at the > time, was/is a really smart move and has saved most of us contorting our > systems with different versions of the "same" software > > I suppose if the ruby developers make such a substantial change to the > language that applications break, then adding flavors to ruby might be > worthwhile. As stated, there is substantial effort required and the need > significant. And as I still have "ports" that use python2 (though most use > python3), I greatly appeciate their effort. > > Is there a specific issue, ie breakage requiring ruby flavors? Thank you Dewayne, that is exactly it! Flavors tends to complexify the ports framework, so they have to be used with caution. the more flavours that are being added the more impacted it has on the package building performances, but also on the complexity of the ports tree itself. It also complexify the life of maintainers who have then to test every possible flavors. We at portmgr have decided to make a rule to try to find the right balance. If you look at flarvors for python you can see that the only supporte flavor are: one flavor for python3 and one flavor for python2 for the reason exposed by Dewayne exactly. Same goes for php. The last point is about end users, lots of end user are confused when you have too many choices, each time a decision is made on the ports tree, the main target should be to think what will happen for end users. how can they chose what is the right version for them etc. What about big "ruby" project like puppet, should we have 3 version of it because ruby is flavored? how will end user pick up which is the right one here. Again we do try to find the right balance. So yes if someone has strong arguments in favor of ruby flavors that will improve the user experience, then we will gladely add it. Also note that if you look at python's flavors, while is simplified a lot the life of end users we have ended up in a quite poor maintenance situation, lots of ports are packages for all the flavours while not working with all of them, many end user programs are being packages in both flavours for the sake of it, but it confuses users for now reasons. That is something we should be careful about. As for the build time arguments, yes it is true as well and if someone wants kill that arguments, there are room of improvements in both poudriere and pkg for which we will be pleased to get working on ;) Best regards, Bapt signature.asc Description: PGP signature
Re: FLAVORS for Ruby
Bottom line: flavors came into being to satisfy specific needs. Python 2 underwent substantial changes during the upgrade to python 3, to the extent that many (most) python applications would cease to function. Similarly php5 to php7. Without flavours the user-base would've been severly impacted during the upgrade transition where some fraction of their applications would fail. Flavours, though I didn't appreciate it at the time, was/is a really smart move and has saved most of us contorting our systems with different versions of the "same" software I suppose if the ruby developers make such a substantial change to the language that applications break, then adding flavors to ruby might be worthwhile. As stated, there is substantial effort required and the need significant. And as I still have "ports" that use python2 (though most use python3), I greatly appeciate their effort. Is there a specific issue, ie breakage requiring ruby flavors? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Tue, Sep 17, 2019 at 01:16:50AM +0900, Koichiro Iwao wrote: > On Mon, Sep 16, 2019 at 08:54:17AM -0600, Adam Weinberger wrote: > > On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao wrote: > > > > > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > > > The issue is that FLAVORS has added a substantial (and painful) > > > > complexity to python ports and python.mk. It means that a number of > > > > people have had to be hyper-vigilant and watch commits closely to catch > > > > errors introduced when people utilize the paradigm incorrectly. It’s a > > > > bitter pill, but it’s accepted because the use-case for multiple > > > > concurrent python versions is essential. > > > > > > > > As Antoine said, inconsistency isn’t a strong enough use case. Which > > > > brings us back to the original question: is there a specific use-case > > > > for concurrent ruby that makes the substantial increase in cognitive > > > > load, complexity, and monitoring worth it? > > > > > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions > > > is essential? > > > > We're going in circles here. I've for the third time now that what > > we'd need to get on board is a use case, a description of the end-user > > problem that we're trying to solve. > > > > What you've provided (for the fourth time in this thread) is a straw > > man argument. What other languages have is irrelevant. We are much > > less concerned with "consistency" than with solving end-user problems > > in a way that fits the specific use case. > > > > Steve seemed interested in the idea. I'd explore it with him, and I > > hope you are able to make it happen. I'm done here. > > Thanks. I see a gap between you and me but I'll give it a try anyway > with swills. > > You: If there's no valid reasons, don't do it. > Me: If there's no invalid reasons, try it. > > I believe that the reason Ruby don't have FLAVORS is just nobody worked > on that. In fact, swills worked on that a little. > > BTW, if I can do something only necessary, what a boring life. What we are all trying to say is that adding flavors for ruby will have a big impact on build time and ressources required for building. If all you want is to have ruby flavors for the kicks of it, then I am glad to tell you that no, it will not be done. Now, the question is, why would someone need to have ruby flavors? The answer cannot be "because it should be fun" or "there is no reason there should not be". Give us a real reason about why it would be required. -- Mathieu Arnold signature.asc Description: PGP signature
Re: FLAVORS for Ruby
On Mon, Sep 16, 2019 at 08:54:17AM -0600, Adam Weinberger wrote: > On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao wrote: > > > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > > The issue is that FLAVORS has added a substantial (and painful) > > > complexity to python ports and python.mk. It means that a number of > > > people have had to be hyper-vigilant and watch commits closely to catch > > > errors introduced when people utilize the paradigm incorrectly. It’s a > > > bitter pill, but it’s accepted because the use-case for multiple > > > concurrent python versions is essential. > > > > > > As Antoine said, inconsistency isn’t a strong enough use case. Which > > > brings us back to the original question: is there a specific use-case for > > > concurrent ruby that makes the substantial increase in cognitive load, > > > complexity, and monitoring worth it? > > > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions > > is essential? > > We're going in circles here. I've for the third time now that what > we'd need to get on board is a use case, a description of the end-user > problem that we're trying to solve. > > What you've provided (for the fourth time in this thread) is a straw > man argument. What other languages have is irrelevant. We are much > less concerned with "consistency" than with solving end-user problems > in a way that fits the specific use case. > > Steve seemed interested in the idea. I'd explore it with him, and I > hope you are able to make it happen. I'm done here. Thanks. I see a gap between you and me but I'll give it a try anyway with swills. You: If there's no valid reasons, don't do it. Me: If there's no invalid reasons, try it. I believe that the reason Ruby don't have FLAVORS is just nobody worked on that. In fact, swills worked on that a little. BTW, if I can do something only necessary, what a boring life. -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao wrote: > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > The issue is that FLAVORS has added a substantial (and painful) complexity > > to python ports and python.mk. It means that a number of people have had to > > be hyper-vigilant and watch commits closely to catch errors introduced when > > people utilize the paradigm incorrectly. It’s a bitter pill, but it’s > > accepted because the use-case for multiple concurrent python versions is > > essential. > > > > As Antoine said, inconsistency isn’t a strong enough use case. Which brings > > us back to the original question: is there a specific use-case for > > concurrent ruby that makes the substantial increase in cognitive load, > > complexity, and monitoring worth it? > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions > is essential? We're going in circles here. I've for the third time now that what we'd need to get on board is a use case, a description of the end-user problem that we're trying to solve. What you've provided (for the fourth time in this thread) is a straw man argument. What other languages have is irrelevant. We are much less concerned with "consistency" than with solving end-user problems in a way that fits the specific use case. Steve seemed interested in the idea. I'd explore it with him, and I hope you are able to make it happen. I'm done here. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > The issue is that FLAVORS has added a substantial (and painful) complexity to > python ports and python.mk. It means that a number of people have had to be > hyper-vigilant and watch commits closely to catch errors introduced when > people utilize the paradigm incorrectly. It’s a bitter pill, but it’s > accepted because the use-case for multiple concurrent python versions is > essential. > > As Antoine said, inconsistency isn’t a strong enough use case. Which brings > us back to the original question: is there a specific use-case for concurrent > ruby that makes the substantial increase in cognitive load, complexity, and > monitoring worth it? PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions is essential? -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Sat, Sep 14, 2019 at 08:39:12AM +0200, Antoine Brodin wrote: > On Sat, Sep 14, 2019 at 6:27 AM Koichiro Iwao wrote: > > On Fri, Sep 13, 2019 at 09:33:43AM -0600, Adam Weinberger wrote: > > > Systems MUST be able to support concurrent installations of python2.7 > > > and actual python. What is your use case for concurrent ruby? > > > > I know the importance of Python 2. Even if it is EoL-ed, it will be > > required over the next a few years because not a few applications don't > > migrate to Python 3. So that's true and reasonable. > > > > Excuse me that I'm answering your question with a question. What about > > PHP? Concurrent installation is a MUST? > > > > FreeBSD ports allows concurrent installations of multiple Ruby versions > > however doesn't allow concurrent installations of rubygems for multiple > > Ruby versions. This inconsistency is the issue for me. > > This isn't a valid reason for me. > Why do you need ruby version 2.4 or 2.5 concurrently installed with version > 2.6? > Is there a bug in version 2.6? You don't understand the issue. The necessity of concurrent Ruby versions isn't the issue. The inconsistency is the issue. If rubygems cannot be installed for multiple ruby versions, FreeBSD ports shouldn't allow to install multiple versions of Ruby. You have doubts about installing multiple ruby versions concurrently, you should also have doubts about why multiple ruby ruby can be installed concurrently Disabling multiple ruby Alternatively, Python 3.5 and 3.6 can be installed concurrently and py- ports can be installed concurrently for each python versions. -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Fri, Sep 13, 2019 at 09:14:01AM -0400, Steve Wills wrote: > We provide multiple versions of Ruby, it would make sense to provide gems > for each version. In fact, I worked on this but never finished it: > > https://reviews.freebsd.org/D1 > > Steve That's nice. I will do anything that I can so if you need help. What should we start from with that to continute? -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
> On Sep 13, 2019, at 22:27, Koichiro Iwao wrote: > >> On Fri, Sep 13, 2019 at 09:33:43AM -0600, Adam Weinberger wrote: >> Systems MUST be able to support concurrent installations of python2.7 >> and actual python. What is your use case for concurrent ruby? > > I know the importance of Python 2. Even if it is EoL-ed, it will be > required over the next a few years because not a few applications don't > migrate to Python 3. So that's true and reasonable. > > Excuse me that I'm answering your question with a question. What about > PHP? Concurrent installation is a MUST? > > FreeBSD ports allows concurrent installations of multiple Ruby versions > however doesn't allow concurrent installations of rubygems for multiple > Ruby versions. This inconsistency is the issue for me. The issue is that FLAVORS has added a substantial (and painful) complexity to python ports and python.mk. It means that a number of people have had to be hyper-vigilant and watch commits closely to catch errors introduced when people utilize the paradigm incorrectly. It’s a bitter pill, but it’s accepted because the use-case for multiple concurrent python versions is essential. As Antoine said, inconsistency isn’t a strong enough use case. Which brings us back to the original question: is there a specific use-case for concurrent ruby that makes the substantial increase in cognitive load, complexity, and monitoring worth it? # Adam — Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Sat, Sep 14, 2019 at 6:27 AM Koichiro Iwao wrote: > On Fri, Sep 13, 2019 at 09:33:43AM -0600, Adam Weinberger wrote: > > Systems MUST be able to support concurrent installations of python2.7 > > and actual python. What is your use case for concurrent ruby? > > I know the importance of Python 2. Even if it is EoL-ed, it will be > required over the next a few years because not a few applications don't > migrate to Python 3. So that's true and reasonable. > > Excuse me that I'm answering your question with a question. What about > PHP? Concurrent installation is a MUST? > > FreeBSD ports allows concurrent installations of multiple Ruby versions > however doesn't allow concurrent installations of rubygems for multiple > Ruby versions. This inconsistency is the issue for me. This isn't a valid reason for me. Why do you need ruby version 2.4 or 2.5 concurrently installed with version 2.6? Is there a bug in version 2.6? Cheers, Antoine ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Fri, Sep 13, 2019 at 09:33:43AM -0600, Adam Weinberger wrote: > Systems MUST be able to support concurrent installations of python2.7 > and actual python. What is your use case for concurrent ruby? I know the importance of Python 2. Even if it is EoL-ed, it will be required over the next a few years because not a few applications don't migrate to Python 3. So that's true and reasonable. Excuse me that I'm answering your question with a question. What about PHP? Concurrent installation is a MUST? FreeBSD ports allows concurrent installations of multiple Ruby versions however doesn't allow concurrent installations of rubygems for multiple Ruby versions. This inconsistency is the issue for me. -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Fri, Sep 13, 2019 at 3:06 AM Koichiro Iwao wrote: > > On Fri, Sep 13, 2019 at 10:00:19AM +0200, Antoine Brodin wrote: > > On Fri, Sep 13, 2019 at 9:45 AM Koichiro Iwao wrote: > > > Hi, > > > > > > I would like to suggest introducing FLAVOR to Ruby ports. > > > > > > AFAIK multiple version of Ruby ports (lang/ruby??) can be installed at > > > the same time. One of these ruby ports will be *default* installed as > > > PREFIX/bin/ruby. In contrast of Ruby lang, rubygem ports cannot be > > > installed for multiple Ruby version at the same time. > > > > > > I would say Ruby and rubygem ports needs FLAVORS like Python ports. > > > In Python ports, the same origin py- ports can be installed for multiple > > > versions such as py27, py35, py36. If the same thing can be done with > > > Ruby ports, FreeBSD Ruby ports will be much improved. > > > > > > I would appreciate if you Ruby folks bounce some ideas off each other. > > > Let me know if someone's already working on FLAVORS on Ruby. Is there > > > something that I can help you with? > > > > Please no. I don't see valid reasons. > > Why? I don't see invalid reasons. Had Ruby FLAVORS already denied in the > past? What's the difference between Rython and Ruby? py- ports can be > installed for py35 and py36 at the same time. Why not for Ruby? > > I'm just brainstorming Ruby FLAVORS. Both positive opinions and negative > opinions are welcome. Systems MUST be able to support concurrent installations of python2.7 and actual python. What is your use case for concurrent ruby? # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Fri, Sep 13, 2019 at 10:00:19AM +0200, Antoine Brodin wrote: > On Fri, Sep 13, 2019 at 9:45 AM Koichiro Iwao wrote: > > Hi, > > > > I would like to suggest introducing FLAVOR to Ruby ports. > > > > AFAIK multiple version of Ruby ports (lang/ruby??) can be installed at > > the same time. One of these ruby ports will be *default* installed as > > PREFIX/bin/ruby. In contrast of Ruby lang, rubygem ports cannot be > > installed for multiple Ruby version at the same time. > > > > I would say Ruby and rubygem ports needs FLAVORS like Python ports. > > In Python ports, the same origin py- ports can be installed for multiple > > versions such as py27, py35, py36. If the same thing can be done with > > Ruby ports, FreeBSD Ruby ports will be much improved. > > > > I would appreciate if you Ruby folks bounce some ideas off each other. > > Let me know if someone's already working on FLAVORS on Ruby. Is there > > something that I can help you with? > > Please no. I don't see valid reasons. Why? I don't see invalid reasons. Had Ruby FLAVORS already denied in the past? What's the difference between Rython and Ruby? py- ports can be installed for py35 and py36 at the same time. Why not for Ruby? I'm just brainstorming Ruby FLAVORS. Both positive opinions and negative opinions are welcome. -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Fri, Sep 13, 2019 at 9:45 AM Koichiro Iwao wrote: > Hi, > > I would like to suggest introducing FLAVOR to Ruby ports. > > AFAIK multiple version of Ruby ports (lang/ruby??) can be installed at > the same time. One of these ruby ports will be *default* installed as > PREFIX/bin/ruby. In contrast of Ruby lang, rubygem ports cannot be > installed for multiple Ruby version at the same time. > > I would say Ruby and rubygem ports needs FLAVORS like Python ports. > In Python ports, the same origin py- ports can be installed for multiple > versions such as py27, py35, py36. If the same thing can be done with > Ruby ports, FreeBSD Ruby ports will be much improved. > > I would appreciate if you Ruby folks bounce some ideas off each other. > Let me know if someone's already working on FLAVORS on Ruby. Is there > something that I can help you with? Please no. I don't see valid reasons. Antoine ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FLAVORS for Ruby
Hi, I would like to suggest introducing FLAVOR to Ruby ports. AFAIK multiple version of Ruby ports (lang/ruby??) can be installed at the same time. One of these ruby ports will be *default* installed as PREFIX/bin/ruby. In contrast of Ruby lang, rubygem ports cannot be installed for multiple Ruby version at the same time. I would say Ruby and rubygem ports needs FLAVORS like Python ports. In Python ports, the same origin py- ports can be installed for multiple versions such as py27, py35, py36. If the same thing can be done with Ruby ports, FreeBSD Ruby ports will be much improved. I would appreciate if you Ruby folks bounce some ideas off each other. Let me know if someone's already working on FLAVORS on Ruby. Is there something that I can help you with? Thanks, -- meta ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
