-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Provide persistent skip-lock option #2200
Comments
If this is done it should be a user preference (like the one discussed in #2197), not a project one. Maybe we can implement a |
Pipenv gives you the virtual environment management. Quite nice IMO. |
Would it be appropriate to place the option within the lockfile itself? |
I think if anything we would want an environment variable for this. We've said no in the past, but I think we've heard it raised enough that we could revisit. I wonder about the security concerns, any thoughts there @ncoghlan? If not I'll run it by Kenneth and we can make a judgment call |
If it makes any difference, I would vote against an environment variable. Having new users to linux/windows set environment variables is rather difficult. I really think the choice should be on a per project basis for the two reasons:
|
Which packages are taking 10s of minutes? If you look at npm, composer, etc, this type of feature is never specified at the project level and there are a lot of good reasons for this — locking is an important element of the behavior we are providing, so disabling it should be an advanced feature, if we choose to offer that at all. You’re right to consider new users. Adding extra knobs on the command line interface is the best way to confuse them. |
Ok, here is 5 minutes, not 10s, which is an eternity to add when trying to teach people to add new packages to implement new features. I also have an i7 for what it is worth.
|
And here is one from my development environment (15:20.04 elapsed)
|
Skipping locking generally isn't a major security concern - OWASP A9 only comes up when you lock your dependencies once, and then never update them (hence why I think figuring out a better way of assessing lock file freshness will let us make So I think if folks running a project want to opt out of dependency pinning, and are happy to accept the resulting time-dependent variation in the way different people have their environments configured, that's an entirely reasonable way to go - it's pretty similar to the situation where folks skip checking |
skip lock can be an environment variable, but not a pipfile feature. |
Title edited to reflect resolution. |
I present another argument for enabling such a feature: The "locking" part of pipenv slows me down drastically while in development. There are times when I just want to work, and not have pipenv take enormous amounts of cpu, internet and time to just install something. I will obviously, lock later when I'm in mood :)
|
Just want to chime in and validate that this is very useful to several people. Makes |
I think if we have the prefix for automatically seeking out environment variables enabled this may work by default, but I’m not totally sure. @uranusjr, any idea? |
Yeah the Click auto prefix thing will probably just work. Is it in the current release yet? |
+1 for having that option inside
It could have both options because some projects doesn't need locking and you don't usually track |
…191-3196-3209 - Closes #2200 - Closes #3112 (via merge) Signed-off-by: Dan Ryan <[email protected]>
I'm always frustrated when
pipenv
wants to lock things. This happens when I install and uninstall things. The problem is that it takes FOREVER to lock big scientific packages (that probably include sample data).I would like to be able to specify completely skipping the locking process within the Pipfile itself.
I've tried to specify
--skip-lock
in many commands that support it, but some commands simply don't support it. Additionally, if I forget to specify--skip-lock
then I have to force quit the program and hope that it maintains a usable state.The text was updated successfully, but these errors were encountered: