Skip to content
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

Closed
AvnerCohen opened this issue Nov 22, 2016 · 5 comments
Closed

Pip version in the Pipfile.lock #28

AvnerCohen opened this issue Nov 22, 2016 · 5 comments

Comments

@AvnerCohen
Copy link

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

@kennethreitz
Copy link
Contributor

kennethreitz commented Nov 24, 2016

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).

@pradyunsg
Copy link
Member

@kennethreitz Have you thought about this?

@kennethreitz
Copy link
Contributor

don't think it's needed at this point

@dstufft
Copy link
Member

dstufft commented Jan 26, 2017

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.

@AvnerCohen
Copy link
Author

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:
http://bundler.io/blog/2015/06/24/version-1-10-released.html#bundled-with

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants