-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pip version in the Pipfile.lock #28
Comments
Adding the pip version as metadata is likely a wise decision, but might not be neccessary. I'll have to think about it. The idea is that the lockfile api will be locked, but the pipfile functionality could possibly be ammended later, potentially, utilizing the mechanisms provided in the pipfile (e.g. custom groups). |
@kennethreitz Have you thought about this? |
don't think it's needed at this point |
I think that we should either do this or #5. Personally I find the idea in #5 to be better largely because one of the goals of splitting this out into a separate library + spec is so that other tooling can reasonably interact with this file besides pip itself. I'm going to close this issue, but mention on #5 that it could possibly also be solved by embedding the pip version instead. |
Sure. no problem. My last comment on this would be to suggest reading through the pains of adding version into the pipfile.lock /gemfile.lock later in the process: pipfile has this unique advantage of being built long after some other platforms, some even has 2nd generation lock file (yarn.lock includes learnings from npm.lock). I really think it would be beneficial to to try and read through some of these existing tools, yarn, which is the latest and greatest of these, is designed with some very interesting features around security and performance. |
Bundler is an amazing tool in ruby-land.
I hope you guys study some of it, as it works really really well.
Specifically, A major pain point there was an addition of the specific "Bundler" version to the Gemfile.lock .
This was a painful migration, but later on allowed much more power to the Bundler authors, if it's in upgrades or in specific lock file changes.
I think if you add this and the specific bundler logic (only update when newer version exists) it will save much pain later on -
rubygems/bundler#3697
The text was updated successfully, but these errors were encountered: