Hi,
I am slowly pushing Ruby 2.3.2 into Fedora.
Unfortunately, part of Ruby 2.3.2 is update of RubyGems and this update has one annoying consequence. RubyGems developers decided, that it is good idea to freeze all strings in generated .gemspec file. But because of this, there might be several rubygem- packages FTBFS. For example, rubygem-execjs fails to build with following errror:
```
+ gem build execjs.gemspec WARNING: See http://guides.rubygems.org/specification-reference/ for help ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["lib/execjs/support/jscript_runner.js", "lib/execjs/support/json2.js"] are not files
```
This is because there are some files removed from the package and the previous sed:
```
+ sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' -e '/files/ s|"lib/execjs/support/json2.js", ||' execjs.gemspec
```
Does not match/substitute anything, due to .freeze call :/ This is the fix for rubygem-execjs:
```
$ git diff diff --git a/rubygem-execjs.spec b/rubygem-execjs.spec index b2df67c..fddb541 100644 --- a/rubygem-execjs.spec +++ b/rubygem-execjs.spec @@ -41,8 +41,8 @@ gem unpack %{SOURCE0}
gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec %patch0 -p1 -sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' \ - -e '/files/ s|"lib/execjs/support/json2.js", ||' %{gem_name}.gemspec +sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js".freeze, ||' \ + -e '/files/ s|"lib/execjs/support/json2.js".freeze, ||' %{gem_name}.gemspec
%build # Create the gem as gem install only works on a gem file
```
I'm sorry for any inconvenience, but suggest to complain to Ruby/RubyGems upstream, since minor/teeny version changes should not break anything ...
Vít
Forgot to mention that this will influence f24 -> Rawhide ... not sure about f23 yet ...
Vít
Dne 18.11.2016 v 21:38 Vít Ondruch napsal(a):
Hi,
I am slowly pushing Ruby 2.3.2 into Fedora.
Unfortunately, part of Ruby 2.3.2 is update of RubyGems and this update has one annoying consequence. RubyGems developers decided, that it is good idea to freeze all strings in generated .gemspec file. But because of this, there might be several rubygem- packages FTBFS. For example, rubygem-execjs fails to build with following errror:
+ gem build execjs.gemspec WARNING: See http://guides.rubygems.org/specification-reference/ for help ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["lib/execjs/support/jscript_runner.js", "lib/execjs/support/json2.js"] are not filesThis is because there are some files removed from the package and the previous sed:
+ sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' -e '/files/ s|"lib/execjs/support/json2.js", ||' execjs.gemspecDoes not match/substitute anything, due to .freeze call :/ This is the fix for rubygem-execjs:
$ git diff diff --git a/rubygem-execjs.spec b/rubygem-execjs.spec index b2df67c..fddb541 100644 --- a/rubygem-execjs.spec +++ b/rubygem-execjs.spec @@ -41,8 +41,8 @@ gem unpack %{SOURCE0} gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec %patch0 -p1 -sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' \ - -e '/files/ s|"lib/execjs/support/json2.js", ||' %{gem_name}.gemspec +sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js".freeze, ||' \ + -e '/files/ s|"lib/execjs/support/json2.js".freeze, ||' %{gem_name}.gemspec %build # Create the gem as gem install only works on a gem fileI'm sorry for any inconvenience, but suggest to complain to Ruby/RubyGems upstream, since minor/teeny version changes should not break anything ...
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Hi Vit,
I'm not sure how this is something that upstream ruby/rubygems can know. How is this a breaking change? It's completely compatible with older versions of ruby.
We're tying our .spec file to very specific details of a .gemspec and hacking it with sed. Anytime we modify upstream source code in .spec files, we are risking breakage.
If you have PRs on upstream repos that will help to remove this technical debt from our spec files, please provide links so that we can support them and work toward their acceptance.
thanks, Joe
On Fri, Nov 18, 2016 at 3:38 PM, Vít Ondruch vondruch@redhat.com wrote:
Hi,
I am slowly pushing Ruby 2.3.2 into Fedora.
Unfortunately, part of Ruby 2.3.2 is update of RubyGems and this update has one annoying consequence. RubyGems developers decided, that it is good idea to freeze all strings in generated .gemspec file. But because of this, there might be several rubygem- packages FTBFS. For example, rubygem-execjs fails to build with following errror:
+ gem build execjs.gemspec WARNING: See http://guides.rubygems.org/specification-reference/ for help ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["lib/execjs/support/jscript_runner.js", "lib/execjs/support/json2.js"] are not filesThis is because there are some files removed from the package and the previous sed:
+ sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' -e '/files/ s|"lib/execjs/support/json2.js", ||' execjs.gemspecDoes not match/substitute anything, due to .freeze call :/ This is the fix for rubygem-execjs:
$ git diff diff --git a/rubygem-execjs.spec b/rubygem-execjs.spec index b2df67c..fddb541 100644 --- a/rubygem-execjs.spec +++ b/rubygem-execjs.spec @@ -41,8 +41,8 @@ gem unpack %{SOURCE0} gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec %patch0 -p1 -sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' \ - -e '/files/ s|"lib/execjs/support/json2.js", ||' %{gem_name}.gemspec +sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js".freeze, ||' \ + -e '/files/ s|"lib/execjs/support/json2.js".freeze, ||' %{gem_name}.gemspec %build # Create the gem as gem install only works on a gem fileI'm sorry for any inconvenience, but suggest to complain to Ruby/RubyGems upstream, since minor/teeny version changes should not break anything ...
Vít
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Hi Joe,
This is what semver [1] says about changes in "patch" version:
PATCH version when you make backwards-compatible bug fixes.
It specifically speaks about "bug fixes". I can't see any bug which freezing all strings in generated .gemspec solves. Such change should never be part of the patch release.
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. And since upstream has no idea what I do with the output and for what purpose, it should do only bugfixes. I thought that is the whole idea of semver ...
Vít
Dne 19.11.2016 v 00:06 Joe Rafaniello napsal(a):
Hi Vit,
I'm not sure how this is something that upstream ruby/rubygems can know. How is this a breaking change? It's completely compatible with older versions of ruby.
We're tying our .spec file to very specific details of a .gemspec and hacking it with sed. Anytime we modify upstream source code in .spec files, we are risking breakage.
If you have PRs on upstream repos that will help to remove this technical debt from our spec files, please provide links so that we can support them and work toward their acceptance.
thanks, Joe
On Fri, Nov 18, 2016 at 3:38 PM, Vít Ondruch <vondruch@redhat.com mailto:vondruch@redhat.com> wrote:
Hi, I am slowly pushing Ruby 2.3.2 into Fedora. Unfortunately, part of Ruby 2.3.2 is update of RubyGems and this update has one annoying consequence. RubyGems developers decided, that it is good idea to freeze all strings in generated .gemspec file. But because of this, there might be several rubygem- packages FTBFS. For example, rubygem-execjs fails to build with following errror: ``` + gem build execjs.gemspec WARNING: See http://guides.rubygems.org/specification-reference/ <http://guides.rubygems.org/specification-reference/> for help ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["lib/execjs/support/jscript_runner.js", "lib/execjs/support/json2.js"] are not files ``` This is because there are some files removed from the package and the previous sed: ``` + sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' -e '/files/ s|"lib/execjs/support/json2.js", ||' execjs.gemspec ``` Does not match/substitute anything, due to .freeze call :/ This is the fix for rubygem-execjs: ``` $ git diff diff --git a/rubygem-execjs.spec b/rubygem-execjs.spec index b2df67c..fddb541 100644 --- a/rubygem-execjs.spec +++ b/rubygem-execjs.spec @@ -41,8 +41,8 @@ gem unpack %{SOURCE0} gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec %patch0 -p1 -sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js", ||' \ - -e '/files/ s|"lib/execjs/support/json2.js", ||' %{gem_name}.gemspec +sed -i -e '/files/ s|"lib/execjs/support/jscript_runner.js".freeze, ||' \ + -e '/files/ s|"lib/execjs/support/json2.js".freeze, ||' %{gem_name}.gemspec %build # Create the gem as gem install only works on a gem file ``` I'm sorry for any inconvenience, but suggest to complain to Ruby/RubyGems upstream, since minor/teeny version changes should not break anything ... Vít _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org <mailto:ruby-sig@lists.fedoraproject.org> To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org <mailto:ruby-sig-leave@lists.fedoraproject.org>
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
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.
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.
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.
Vít
[1] https://github.com/rubygems/rubygems/commit/486b0549a74cdd9a4031c5ffbc511f7f... [2] http://pkgs.fedoraproject.org/cgit/rpms/rubygem-actionpack.git/commit/?id=eb...
On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch vondruch@redhat.com wrote:
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".
As a developer of rpms, you must also have things that are intentionally public and other things that are not intentionally public. There are always gray areas where "public API" is based on your perspective.
For anyone that doesn't consume gemspec contents line by line, that's clearly not public. Since you do, you think it's public.
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?
Technically, they're ruby compatible. Again, this is for examination so I would think it's not meant as a public API.
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".
You probably have been inspecting gemspec contents before 2013 but this change is over 3 years old and has shipped with ruby since ruby 2.1 so it's not quite recent.
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.
Maybe we had to modify gemspecs in 2011. Is it possible to summarize what we need to modify gemspecs for? Since rubygems is telling us it's not a public API, even if we can't remove all of the gemspec modifications, it's probably best to try to remove the easier ones.
Note, we can continue to modify the gemspecs with the knowledge that any new rubygems version could break us. That's a risk we can choose to accept.
Dne 23.11.2016 v 03:53 Joe Rafaniello napsal(a):
On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch <vondruch@redhat.com mailto:vondruch@redhat.com> wrote:
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".You probably have been inspecting gemspec contents before 2013 but this change is over 3 years old and has shipped with ruby since ruby 2.1 so it's not quite recent.
My point was that somebody even prior my time explored this way and started to use it. There were no comments about "examination". Once they were used, there was no reason to re-evaluate if the method is sound or not, until it broke.
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.Maybe we had to modify gemspecs in 2011. Is it possible to summarize what we need to modify gemspecs for?
There are three (at minimum) reasons why we need to modify the .gemspec and I assume every distribution is doing it:
1) Get rid of platform specific dependencies. E.g. rubygem-listen depends on Mac, Windows, BSD specific libraries and there is obviously no reason to ship them on Linux.
2) Sometimes we need to modify the file list. For example in the case of execjs, there is bundled some windows specific js script. Since it is "bundling" case and it is Windows specific, we decided that we won't ship the specific file and therefore we need to remove it from the file list.
3) Change the version dependencies. As we typically ship just one version of library, sometimes we are in hard position that we have version X, which is used by some library, while the other library depends on version Y. There is not always any reason behind it other then some of the libraries was not updated for some time.
Also please note that there are two places where these modifications might happen. Historically, we mostly modified just the .gemspec file from the specifications/ folder, but since there was introduced the gem repackaging step (which I hate from the very beginning, but I lost the battle), the modifications might happen earlier.
Since rubygems is telling us it's not a public API, even if we can't remove all of the gemspec modifications, it's probably best to try to remove the easier ones.
The (1) and (3) should be covered now by the newly introduced gemspec_add_dep and gemspec_remove_dep macros [1]. So it is probably good start to use them. But please note, that I introduced these macros in Rawhide one month ago and they will be part of 2.3.3 and 2.2.6 updates, which are in updatest-testing. It is unfortunate that this is not breaking just Rawhide, but also stable releases.
Note, we can continue to modify the gemspecs with the knowledge that any new rubygems version could break us. That's a risk we can choose to accept.
Yes, this is expected and it won't happened for the fist time probably (there was introduce for example the Bundler stub line, for example). And I am fine if that happens in Rawhide.
But still, patch release of RubyGems is not "new" version for me. May be we need disagree on that.
Also please note that there is difference if the change is purely RubyGems change, but since this version of RubyGems was pulled into Ruby, it is much harder situation ....
Vít
[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/commit/macros.rubygems?id=4...
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.
Jason
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
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 ...
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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
Dne 28.11.2016 v 12:39 Mamoru TASAKA napsal(a):
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.
I reverted this feature for stable Fedoras. Please test the updates:
F25: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1270a9a624 F24: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1ce385e9d8
F23 should not suffer this issue. And please don't forget to adjust your packages in Rawhide.
Thx
Vít
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@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org
ruby-sig@lists.fedoraproject.org
-
Chris Arcand -
Jason Frey -
Joe Rafaniello -
Mamoru TASAKA -
Vít Ondruch