[Lockfile] Store each rubygems remote separately#3593
[Lockfile] Store each rubygems remote separately#3593
Conversation
Remove bundle_ruby
Remove deployment.rb and vlad.rb
Deprecate and remove capistrano.rb
Invert defaults for caching during install
[ci skip]
[ci skip]
Remove unused class variable
This solution uses a less-than-ideal method to add Thor-formatted printing to STDERR. Because Thor doesn't offer this out-of-the-box, I've used Thor's internals to format a message and pass it to Thor's stderr. Since this uses protected methods, changes under the hood in Thor may break this. If this happens, tests will fail. I also added basic tests to ensure other print methods from `Bundler::UI::Shell` continue printing to STDOUT.
…s-1-99-dev Edit bundle-config.ronn and bundle-install.ronn re: previously remembered flags
|
Do we need to explicitly opt this in to travis? Or just push a new commit now that 2-0-dev is on the list? |
[SourceList] Warn when adding a git source using the git procotol
|
All fails, so I guess this PR still needs some work. :) |
|
@indirect pretty sure 2-0-dev is all fails to begin with :p |
|
Oh we should probably fix that then :P |
segiddins
force-pushed
the
segseparate-lockfile-sources
branch
from
e99aa11 to
ec289da
Compare
|
I don't really see how I can make this work, given the rubygems aggregate exists. Maybe marking the aggregate as such as an entry in the options hash? |
|
I think the endgame is to get rid of the aggregate, but I have no idea how hard that is right now. On Sat, May 16, 2015 at 8:32 PM, Samuel E. Giddins
|
|
Yeah, one of the main reasons the rubygems aggregate exists is because the remotes are not stored separately in the lock file. Hopefully, with this change the aggregate can be removed. Another reason is to handle multiple top-level sources. Should we disallow that entirely in 2.0? Even if we keep allowing it, it would be good to refactor Source::Rubygems to be single-source only, and handle multiple top-level sources with something like composite pattern. |
|
I would strongly prefer that we stop allowing multiple top level sources in 2.0. It's already opt-in as of 1.8 via config, and we've said it will become an error in 2.0. On Mon, May 18, 2015 at 2:42 PM, Tim Moore notifications@github.com
|
|
👍 that should simplify things a lot. Then all rubygems sources have a single remote, and the only special thing about the top level one (after the Gemfile is eval'ed) is that it acts as a fall back source for transitive dependencies that aren't found in the source of the parent gem. |
|
Then how do we mark the top level one as such? -Samuel E. Giddins On May 18, 2015, at 4:47 PM, Tim Moore notifications@github.com wrote: that should simplify things a lot. Then all rubygems sources have a single remote, and the only special thing about the top level one (after the Gemfile is eval'ed) is that it acts as a fall back source for transitive dependencies that aren't found in the source of the parent gem. — |
Do you mean in memory at runtime, or in For the former, we could still have a special instance variable in For the latter, do we need to? |
|
Yes, we need to for the latter, or we’ll need to make major changes to how we detect if the sources in the definition have changed.
|
|
Well, we could add a line like |
|
But there will still be some rearrangements that we wouldn't be able to detect? I think.... -Samuel E. Giddins On May 18, 2015, at 9:09 PM, Tim Moore notifications@github.com wrote: Well, we could add a line like default: true to the GEM section, but I would have thought that we'd be able to detect changes just by looking at which gems come from which sources. — |
|
It's possible (like maybe if you swap a source block with the top level) but maybe it isn't relevant because the behaviour would be the same? |
|
@segiddins any interest in finishing this off, or should we leave it for @smlance if he has time? |
|
@indirect I probably can, just need to get rid of the aggregate |
|
@TimMoore any chance you want to take this over? Or should I just close? |
|
I'm happy to get this done myself as soon as GSoC stuff is taking up less of my time. On Mon, Aug 17, 2015 at 8:20 PM, Samuel E. Giddins
|
|
I should have some time this weekend. |
|
@TimMoore is it worth keeping this open, or would we be better off starting from scratch? |
|
Oh wow, where have the months gone? Let's close it and reassess. |
… lockfile format
… new lockfile format
5 participants
Closed https://trello.com/c/JlXm2yZy/100-split-gem-server-sources-in-the-lock-file.
I don't this is done yet, but I want to go to bed.
\c @TimMoore @indirect