And what I am doing with the "gem spec" output is my business, I might just checking its checksum, or I might modify it, it doesn't really matter.

The specification command allows you to extract the specification from a gem for **examination**.

Here's the Pull Request and commit that introduced the change. https://github.com/rubygems/rubygems/pull/1371 The Pull Request shows that the purpose of the change is to fix a memory allocation issue. On large projects with a number of Rubygems it can reduce String allocations by nearly 50%. I think this is an acceptable bug fix with respect to SemVer.

Additionally, SemVer is around versioning of the public API. As the Gem specification source that is generated by Rubygems is not actually part of the public API, I don't even think SemVer applies.

Modifying them (via sed, no less) is akin to monkey-patching private methods, which is not covered by SemVer. May I suggest that instead of using sed against the source

, which could potentially corrupt the file into invalid Ruby, that we use Ruby to parse Ruby itself? Since the file is valid Ruby, Ripper could be use to parse the source, manipulate the S-expressions, and then emit the valid, modified Ruby. This feels more forward-compatible in the long run.

Dne 21.11.2016 v 16:48 Chris Arcand napsal(a): > This doesn't break semver. > > It does not introduce a backwards incompatible change from the Ruby ecosystem's perspective (the change is within internal specifications and is completely compatible with previous versions of Ruby/RubyGems). You're expecting a semver contract with internal gem specifications that doesn't exist. For better or worse, there are more views then just "Ruby/Rubygems".

> >> And what I am doing with the "gem spec" output is my business, I might just checking its checksum, or I might modify it, it doesn't really matter. > Indeed, you can do whatever you want with the output. But note, there's further proof your semver contract isn't applicable here - from the RubyGems specification, `gem spec`'s purpose is described as follows: > >> The specification command allows you to extract the specification from a gem for **examination**. > There's no break in contract, as you're still getting what RubyGems uses...for examination. And "examination" means that the result of "gem spec" might be different from version to version and can be freely changed?

Not mentioning that this wording was introduced quite recently [1] and from the commit, there is no obvious that it would be meant as "the ouput is just informative, don't use it for anything".

Just for your information, we are modifying .gemspec files for as long as I remember. This [2] is for example one of my first commit to ActionPack and you'll see that we were modifying .gemspec files at that time. May be it is not nice, but unfortunately, we have to do it.

Dne 21.11.2016 v 17:33 Jason Frey napsal(a): > Here's the Pull Request and commit that introduced the change. > > https://github.com/rubygems/rubygems/pull/1371 > > The Pull Request shows that the purpose of the change is to fix a memory allocation issue. On large projects with a number of Rubygems it can reduce String allocations by nearly 50%. I think this is an acceptable bug fix with respect to SemVer. Thx for the pointer. It might or might not be acceptable. Looking at the consequences, it is not acceptable for me. I don't think that the memory allocation was new issue introduced in rubygems 2.5.x, so it is not regression. But somebody else might have different opinion and of course sometimes it is hard to foresee the consequences. In this case I would rather hear "sorry and will try to not break things next time for you" ... > Additionally, SemVer is around versioning of the public API. As the Gem specification source that is generated by Rubygems is not actually part of the public API, I don't even think SemVer applies. So output of "gem spec" is not public API? How comes? Is it too much to expect that with patch version change, the output will be still the same unless it explicitly changed to fix some regression? > Modifying them (via sed, no less) is akin to monkey-patching private methods, which is not covered by SemVer. > > May I suggest that instead of using sed against the source There are cases where sed is used and other cases where the .gemspec files are patched. I prefer "sed" a bit, because althouhg its a bit more fragile, it is more flexible on the other hand. > , which could potentially corrupt the file into invalid Ruby, that we use Ruby to parse Ruby itself? Since the file is valid Ruby, Ripper could be use to parse the source, manipulate the S-expressions, and then emit the valid, modified Ruby. This feels more forward-compatible in the long run. This is good tip and just recently, I introduced some macros into Fedora, which are using similar approach, just using RubyGems constructs [1]. I find it simpler to understand. But the thing is that I know just about breakages in my packages, but I don't know what else is broken and what different approaches people are using to modify the .gemspec. Yes, removing some files from .gemspec file list looks to be something one needs to do from time to time, but so far it was not that common practice to invest energy to something more complex then sed/patch. Vít [1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/macros.rubygems#n61 _______________________________________________ ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org

Vít Ondruch wrote on 11/28/2016 07:41 PM: > Actually, since there were some people hitting this issue on devel ML, > shouldn't we revert this patch for stable Fedoras? I.e. 23-25 and keep > it for Rawhide only? There are two days left until the updates become > stable ... Honestly speaking, although ruby upstream say that "gem specification" output is ruby internal, I don't think such "memory optimization" which may break things like this should be brought into _PATCH_ release change, such change should be introduced into at least minor release change, the best is major release change. +1 for reverting this change on stable Fedora.

Mamoru > > > Vít > > > Dne 22.11.2016 v 12:46 Vít Ondruch napsal(a): >> >> Dne 21.11.2016 v 17:33 Jason Frey napsal(a): >>> Here's the Pull Request and commit that introduced the change. >>> >>> https://github.com/rubygems/rubygems/pull/1371 >>> >>> The Pull Request shows that the purpose of the change is to fix a >>> memory allocation issue. On large projects with a number of >>> Rubygems it can reduce String allocations by nearly 50%. I think >>> this is an acceptable bug fix with respect to SemVer. >> Thx for the pointer. It might or might not be acceptable. Looking at >> the >> consequences, it is not acceptable for me. I don't think that the >> memory >> allocation was new issue introduced in rubygems 2.5.x, so it is not >> regression. But somebody else might have different opinion and of >> course >> sometimes it is hard to foresee the consequences. In this case I would >> rather hear "sorry and will try to not break things next time for >> you" ... >> >>> Additionally, SemVer is around versioning of the public API. As >>> the Gem specification source that is generated by Rubygems is not >>> actually part of the public API, I don't even think SemVer applies. >> So output of "gem spec" is not public API? How comes? Is it too much to >> expect that with patch version change, the output will be still the >> same >> unless it explicitly changed to fix some regression? >> >>> Modifying them (via sed, no less) is akin to monkey-patching >>> private methods, which is not covered by SemVer. >>> >>> May I suggest that instead of using sed against the source >> There are cases where sed is used and other cases where the .gemspec >> files are patched. I prefer "sed" a bit, because althouhg its a bit >> more >> fragile, it is more flexible on the other hand. >> >>> , which could potentially corrupt the file into invalid Ruby, that >>> we use Ruby to parse Ruby itself? Since the file is valid Ruby, >>> Ripper could be use to parse the source, manipulate the >>> S-expressions, and then emit the valid, modified Ruby. This feels >>> more forward-compatible in the long run. >> This is good tip and just recently, I introduced some macros into >> Fedora, which are using similar approach, just using RubyGems >> constructs >> [1]. I find it simpler to understand. >> >> But the thing is that I know just about breakages in my packages, but I >> don't know what else is broken and what different approaches people are >> using to modify the .gemspec. Yes, removing some files from .gemspec >> file list looks to be something one needs to do from time to time, but >> so far it was not that common practice to invest energy to something >> more complex then sed/patch. >> >> >> Vít >> >> >> >> >> [1] >> http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/macros.rubygems#n61 >> >> >> _______________________________________________ >> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org >> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org > > _______________________________________________ > ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org > _______________________________________________ ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org