warning: constant Gem::ConfigMap is deprecated #3068
Comments
|
I have exactly the same issue. |
|
Can you tell us more information about your ruby installation? Does the |
|
You can easily replicate it with the following Dockerfile: Hopefully, it provides you with all details necessary. |
|
It’s the distribution issue, especially debian. |
|
It sounds like this is fixed in Maybe we should only ship this kind of deprecations on new rubies, so that distributions can update this at their own pace? |
|
We couldn't control the patches on the Linux distributions. Because they will backport patches across Ruby versions. |
|
same issue on ubuntu 18.04 |
Yeah, I mostly agree, but maybe deprecating things only on the newest ruby could be a good compromise between allowing us to move forward and deprecate things, but still avoid these kind of OS packaging issues, because when the new ruby gets shipped as a new OS package, deprecations will be fixed on it without the need for backports to older rubies. I'll try raise an issue at https://salsa.debian.org/ruby-team/rubygems-integration to try get feedback about this and figure out the best way to do things. In the mean time, the workaround (or maybe final "fix" depending on what conclusions we reach) is: never upgrade rubygems through |
👍
Completely agreed. If we will support the upgrading the rubygems provided by the operating system., We should test them with CI. |
|
This probably doesn't help now you've identified the issue, but FWIW this is on Mint 19.1 after doing a |
|
we're seeing this issue as well, but only with
Going through the logs to see if there have been any recent updates. Rubygems 3.1.1 |
|
I created a thread in debian mailing lists to ask about this: https://lists.debian.org/debian-ruby/2020/01/msg00015.html. Also, if I may ask the people getting this issue. Why are you upgrading rubygems? |
|
Regarding my previous question, let me clarify. Is it because of some instructions or documentation you read somewhere, or is it just because you wanted to pick up some bug fix or feature, or simply run the latest version? I'm asking because maybe we should clarify such documentation if it exists. |
|
@deivid-rodriguez I was having a problem which unfortunately I can't remember the detail of now, and a suggestion on stack exchange was to try running the update. Have since switched to rbenv and not looking back. I'm surprised one of the ruby version managers isn't distributed by default in the distros. |
|
I'm having this problem just by running ruby. I just udated Rubygems and it started happening. |
|
I got a reply from debian packagers, see https://lists.debian.org/debian-ruby/2020/01/msg00025.html. To summarize:
I think deprecating things only on newest rubies is a good compromise, and it also gives us a clear deprecation horizon. We can fully remove the deprecated code once we drop support for the ruby version where the deprecation is first being printed. I think it should be easy to implement, what do you think @hsbt? |
|
A quick tip for anyone finding this issue before a newer version fixes things: I got rid of the warnings by downgrading to the latest RubyGems that doesn't have the deprecation warning: I did this on Ubuntu 18.04 and it worked nicely. Another option may be to set the env variable |
Bundler asked me to do this. |
@deivid-rodriguez |
|
It's perfectly fine to upgrade rubygems, we're actually very happy that people use the latest version and pickup our bugfixes and new features. The problem is that if for some reason you're using ruby through OS packages, you shouldn't upgrade rubygems through RUN apt install ruby
RUN gem update --systemwe should fix it. |
|
OK, my problem has turned to be another bundler-Gemfile.lock quirk (which I "workarounded" with the superfluous |
The bundler asked me to upgrade rubygems.
I did the same thing here on Ubuntu 18.04 and it's fixed. |
A recent update in the Linux VM images used by Azure Pipelines surfaced a new problem in the "Documentation" job. Apparently, this warning appears 396 times on `stderr` when running `make doc`: /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated This problem was already reported to the `rubygems` project via rubygems/rubygems#3068. As there is nothing Git can do about this warning, and as the "Documentation" job reports this warning as a failure, let's just silence it and move on. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I have same problem, but in different circumstances. Using Afterwards I updated bundler to On versions I was hoping I can switch to Ruby 2.7 still on Ubuntu 18.04. EDIT: Using |
|
I'm guessing |
|
it seems it will be backported from debian at some point - https://git.launchpad.net/ubuntu/+source/rubygems-integration/log/ |
Yep. It is Ruby 2.7.0. |
How to fix it ??? |
|
@lavie3k Your issue is different from this pull-request. Can you file it the new issue?
This tracker is NOT the support forum. If you want to get the support for the several issues, https://stackoverflow.com/ may helps you. |
|
I encountered this issue because the document How to Upgrade to Bundler 2, tells you to do There should be a big warning in that document that doing this may destabilise your system. I would not have entered this command if I had been thinking straight! What you get with an Ubuntu release is a set of packages that have been carefully tested, so that they work together. Doing For what it's worth, I think it was a mistake for Bundler to depend on on RubyGems 3, as it did when it was announced:
Looking again at How to Upgrade to Bundler 2, I see that it now says:
I wonder what brought about that change??? Anyway, this has been a bit of a rant, but
|
|
That's for your feedback @matt-wallis
Yep, this was a mistake.
Yeah, we're working towards that goal. @simi just suggested this which I find a very good idea. We also provided a way for OS packagers to completely disable |
@deivid-rodriguez you're welcome.
Might a solution to this issue for the people who are here becasue of bundler's advice be |
That's the oldest |
That makes sense.
Sounds like a good idea. I guess this problem will go away for those on Ubuntu 18.04 once they upgrade to 20.04? I see that 20.04.1 is due 2020-08-06, and at this point 18.04 users will be notified that a new OS version is available. |
|
We now provide a way for OS packagers to disable non-OS rubygems upgrades, and we hope it will be used. There's also workaround steps in this thread. We should be more careful in the future when deprecating stuff used by OS package extension, but I think I'm going to proceed with closing this, because there's not too much we can do at this point, and fixed OS packages will slow start reaching users so this will be less of an issue as time passes. |
|
Ok, closing then! |
|
I was getting these warning messages today. Output: As @rennex said, I downgraded with and after some more of these messages, Fixed! 🎉 |
|
@voghDev Too bad that you didn't see that you should have downgraded to 3.0.8 🎉 |
Thanks for the observation. I'll "down-upgrade" to 💜 |
This introdduces a local development environment based on docker, thus removing the need to install ruby/docker and maintain this on the local dev machine. Based on rubygems/rubygems#3068 Updates based on rubygems/rubygems#3068
|
ruby 2.6.1 After running So my conclusion, since rails testing essentially recreates the database then destroys it, that to eliminate the warnings the db needs to be exported, dropped, recreated and re-imported? Is this assumption correct? [checking in case I may be missing something and blunder into something] |
worked on kali |
|
I was getting these warning messages today. Please suggest me . Output:
|
|
so sorry but: |
|
You should most likely downgrade manually. |
|
Resolvi com o comando: |
and others
I'm having a problem
My current problem is I'm running the latest version of ruby gems and I'm seeing deprecation warnings:
This issue is related to:
Here are my current environment details:
I will abide by the code of conduct
The text was updated successfully, but these errors were encountered: