pmxbot IRC Log Viewer

[13:58:20] <biryukov> Hi. What are you guys working on now? Just curious.

[14:31:45] <McSinyx[m]> hi biryukov, are you referring to a certain project or to what PyPA in general is doing at the moment?

[15:32:17] <GPHemsley> techalchemy: Can you comment on this comment and the one after? https://github.com/pypa/pipenv/issues/3150#issuecomment-522947210

[15:33:06] <GPHemsley> the behavior of `pipenv install` appears to have changed, and it's unclear if that was intentional, and what the "right" commands to use are for various scenarios

[15:33:39] <techalchemy> GPHemsley, what do you mean it changed

[15:33:46] <techalchemy> are you referring to the bug ?

[15:34:28] <techalchemy> I don't think bugs require full usage updates, we are pushing a bugfix release today...

[15:34:40] <GPHemsley> per the comment, `pipenv install` now installs from the lockfile instead of the pipfile

[15:35:12] <techalchemy> i dont know what you mean that the behavior of that changed, it's been that way for a looooong time

[15:35:16] <techalchemy> that's the entire point of pipenv

[15:35:47] <GPHemsley> the comment provides better details, but... what is the difference between `pipenv install` and `pipenv sync`?

[15:36:05] <techalchemy> install will lock if your lockfile is not up to date

[15:36:13] <GPHemsley> yeah, that's not happening anymore

[15:37:00] <techalchemy> I don't know what that means

[15:37:04] <techalchemy> can you elaborate

[15:37:24] <GPHemsley> running `pipenv install` no longer updates the lockfile with changes

[15:37:59] <techalchemy> so lockfiles never get updated?

[15:38:02] <GPHemsley> correct

[15:38:05] <techalchemy> i.e. writing lockfiles is broken

[15:38:08] <GPHemsley> it behaves identically to `pipenv sync`

[15:38:08] <techalchemy> as of when

[15:38:27] <GPHemsley> sometime between 2018 and 2020... didn't dig in

[15:38:35] <techalchemy> erm, i mean that isn't true at all

[15:39:36] <GPHemsley> are you sure?

[15:43:33] <techalchemy> GPHemsley, https://bpa.st/Q77A

[15:43:34] <techalchemy> yes

[15:44:26] <techalchemy> here is an example of me updating my pipfile by hand and adding something and rerunning 'pipenv install'

[15:44:38] <techalchemy> pipenv immediately detects the change and re-locks, and that is reflected in the lockfile

[15:45:36] <GPHemsley> I'm talking about without updating the pipfile

[15:46:06] <techalchemy> ?

[15:46:29] <techalchemy> that's what triggers locking...

[15:46:35] <GPHemsley> if you have deps of "*" and you run `pipenv install`, you should get the latest version of those deps

[15:46:44] <techalchemy> adding or removing a package is what triggers locking

[15:46:50] <techalchemy> if you want to update, run the update command

[15:47:00] <GPHemsley> this is a difference of behavior from 2018

[15:47:03] <techalchemy> no it isnt

[15:48:25] <techalchemy> if a lockfile is present and the relevant pipfile had no dependency updates, there is no resolution performed, thats' what lockfiles are for -- reproducibility

[15:48:38] <techalchemy> if we re-locked on every 'install' run there would be no point in even having a lockfile

[15:48:48] <techalchemy> and also no reproducibility

[15:52:12] <GPHemsley> ok, I see what my problem is

[15:52:29] <techalchemy> GPHemsley, what is it?

[15:52:30] <GPHemsley> it appears to go back to `pipenv uninstall --keep-outdated` behavior changing

[15:52:48] <techalchemy> oh yeah --keep-outdated changed substantially

[15:52:59] <GPHemsley> I got so used to that behavior that I internalized the wrong behavior of `install` and `sync`

[15:53:00] <techalchemy> as in, got implemented

[15:53:04] <techalchemy> but still sucks

[15:54:02] <techalchemy> FWIW the issue you posted deserves a reply and the pipenv user flow deserves a writeup

[15:54:12] <GPHemsley> yeah, I still have questions about that

[15:54:21] <techalchemy> dont we all

[15:54:24] <GPHemsley> hah

[15:54:28] <techalchemy> :p

[15:54:58] <techalchemy> I wrote out what I want to aim for on a flight like a year ago

[15:55:16] <techalchemy> but like, on physical paper with a pen

[15:55:18] <GPHemsley> so if the pipfile has not changed, is it correct that `pipenv install --deploy`, `pipenv install`, and `pipenv sync` are all the same?

[15:55:26] <GPHemsley> that's often my preferred method :)

[15:56:07] <techalchemy> right, pipenv install --deploy should fail loudly if your pipfile and lockfile are not in agreement (the 'hash' in your lockfile is just a hash of the contents of your pipfile)

[15:57:10] <techalchemy> so at runtime it hashes your pipfile and compares against the lockfile hash, --deploy will throw an error, 'sync' will just warn that it is installing old stuff, and 'install' will re-lock first

[15:57:45] <techalchemy> 'lock' and 'sync' are meant to be the 2 atomic steps of the workflow basically

[15:58:11] <GPHemsley> and the difference between 'install' and 'update' is just whether it checks the pipfile hash?

[15:58:44] <techalchemy> i.e. resolve dependencies / update lockfile (but never install anything) or manipulate environment (but never resolve/touch the lockfile)

[15:59:29] <techalchemy> yeah update doesn't care about whether the lockfile hash is ok, since that won't tell us anything about whether the packages are current

[15:59:45] <GPHemsley> 'install' = maybe 'lock', then 'sync'; 'update' = 'lock', then 'sync' ?

[16:00:02] <techalchemy> right

[16:00:07] <GPHemsley> got it, ok

[16:00:09] <techalchemy> and these days install doesn't necessarily sync anymore either

[16:00:19] <GPHemsley> right, because it checks first

[16:00:25] <techalchemy> yeah

[16:00:25] <GPHemsley> if things are already installed

[16:00:53] <techalchemy> that will be a nice change, i think

[16:01:02] <GPHemsley> definitely

[16:02:20] <GPHemsley> so going back to my original --keep-outdated issue... what changed, exactly?

[16:02:38] <GPHemsley> or, perhaps put another way, what didn't work before?

[16:05:51] <techalchemy> lol

[16:05:56] <techalchemy> mostly everything

[16:06:14] <techalchemy> it's not a very good command honestly

[16:06:43] <techalchemy> it's meant to do as little as possible when adding a package to the pipfile, i.e. avoiding updates that aren't necessary

[16:07:45] <techalchemy> unfortunately a byproduct of locking often involves removing packages that aren't deemed necessary anymore, so if you are on python 3 and still need python 2 packages to stick around they will still get dropped

[16:08:42] <GPHemsley> and there is no command that modifies the pipfile without also relocking?

[16:08:55] <techalchemy> there is, `install <blah>`

[16:09:15] <GPHemsley> that doesn't relock?

[16:09:24] <techalchemy> oh sorry it does

[16:09:52] <techalchemy> sometimes i want to just update <blah> and its descendents, without touching *anything* else at all no matter what, and there is no way to do that currently

[16:10:05] <GPHemsley> right, that's what I thought

[16:10:19] <GPHemsley> with 'uninstall' being the inverse

[16:10:25] <techalchemy> (because you still have to resolve everything in case some other package depends on one of the descendents or one of the new ones etc)

[16:10:33] <GPHemsley> or the reverse, I get

[16:10:36] <GPHemsley> *guess

[16:10:53] <techalchemy> uninstall is substantially easier but nobody spends any time thinking about it for whatever reason

[16:10:54] <GPHemsley> so, switching gears a moment

[16:11:15] <techalchemy> once something is installed, we know what depends on it roughly

[16:11:28] <techalchemy> & vice versa, so removing it isn't so bad

[16:11:41] <GPHemsley> is there a diference between `pipenv lock` and `pipenv lock --dev`? does the --dev flag do anything?

[16:11:57] <techalchemy> hm for locking? i dont actually know

[16:12:00] <techalchemy> i would be surprised

[16:12:21] <GPHemsley> it seems to maybe be tied in with -r

[16:12:35] <techalchemy> that's probably the main reason the flag is there

[16:12:49] <GPHemsley> and now there's also --dev-only

[16:12:51] <techalchemy> we made the call a long time ago to not allow dev dependencies that would conflict with primary ones

[16:13:07] <GPHemsley> hmm

[16:13:14] <GPHemsley> that makes sense

[16:13:56] <techalchemy> because they get implicitly merged when you install with --dev & it'd make it possible to have a dev environment that was different from your production one

[16:14:10] <GPHemsley> the confusion, of course, is that --dev is significant to other commands not using requirements.txt

[16:15:45] <techalchemy> yeah install --dev, lock -r --dev, update --dev, the last change to the flag was to make them all consistent -- so they all mean 'include dev dependencies along with main ones'

[16:16:04] <techalchemy> that's why the --dev-only flag was added, basically

[16:20:49] <GPHemsley> the difference being that 'lock' also means that, from the perspective of the lockfile

[16:21:03] <GPHemsley> but yeah, ok

[16:21:04] <GPHemsley> thanks

[16:32:55] <GPHemsley> techalchemy: so one more thing

[16:33:31] <GPHemsley> given that `pipenv uninstall --keep-outdated xyz` doesn't remove the xyz package from the lockfile... that's a bug, right?

[16:33:55] <GPHemsley> independent of the --keep-outdated part and the redesign that needs to happen to the whole function set

[16:49:14] <techalchemy> i mean, arguably?

[16:49:18] <techalchemy> @ GPHemsley

[16:49:39] <techalchemy> i should say, given the current functionality i'd probabaly go with 'yes'

[16:50:04] <techalchemy> but if we rethink command and arguments that are less confusing, ???

[16:50:27] <techalchemy> not sure what functionality --keep-outdated would have in those circumstances, the flag is inherently confusing to me

[16:50:35] <techalchemy> and i designed it -_-

[16:55:49] <GPHemsley> XD

[21:18:33] <sumanah> ok, I'm gonna tackle a few more SourceForge support requests now

[21:22:00] <sumanah> take it from 137 down to 100

[22:19:07] <sumanah> ok, down from 137 to 96.

[22:20:59] <tos9> should I ask what pypa has to do with sourceforge or vice versa

[22:21:09] <sumanah> tos9: once upon a time:

[22:21:20] <sumanah> https://sourceforge.net/p/pypi/support-requests/

[22:22:16] <tos9> oh. geez.

[22:22:28] <sumanah> tos9: those had to do with the legacy PyPI and there are some support requests, especially around account recovery and package name transfers, that still needed or still need attending to.... so I'm closing them and saying "please reopen at https://github.com/pypa/pypi-support/issues " or on the Warehouse issue tracker where appropriate

[22:23:34] <sumanah> a few days ago there were about 270 open issues. I dealt with about half of them then. Now I'm taking them a few dozen at a time

[22:24:21] <sumanah> I'm using some boilerplate text I've written, and customizing it for responses when necessary. In some cases I have learned something

[22:24:34] <sumanah> like with https://sourceforge.net/p/pypi/support-requests/523/

[22:24:53] <tos9> I would be interested in the number of those that anyone responds to :D

[22:25:01] <tos9> considering how long they've hopefully been sitting there

[22:25:16] <sumanah> already one person has reopened their transfer request on the new tracker https://github.com/pypa/pypi-support/issues/425

[22:25:46] <tos9> amazing (great though.)

[22:26:22] <sumanah> folks who were having login issues in 2017 and don't do much in the Python world may come back and say "oh great, they fixed it" and successfully be able to log in

[22:26:30] <sumanah> we'll see!

[22:27:06] <sumanah> I'm sure many of them already fixed their problems via other means, or drifted away, etc

[22:27:29] <sumanah> how are you doing tos9 ?

[22:28:45] <tos9> sumanah: alive, well (well enough I suppose)

[22:28:46] <tos9> sumanah: you?

[22:28:51] <sumanah> Same

[22:29:15] <tos9> I forget, are you in manhattan

[22:29:16] <tos9> or outside

[22:29:26] <sumanah> tos9: Queens

[22:29:34] <tos9> ah

[22:29:45] <tos9> how rowdy is where you are

[22:30:40] <sumanah> I don't know. When I hear sirens, it might be because ambulances need to get to hospitals. tos9 you live in .... Montreal? Sorry, I have forgotten

[22:32:19] <tos9> sumanah: :) -- I'm in Manhattan

[22:32:27] <sumanah> tos9: ugh, I'm sorry!

[22:32:39] <tos9> ha, no worries.

[22:32:41] <sumanah> ok, down to 92 open requests in the SourceForge tracker

[22:32:58] <sumanah> Manhattan might as well be Montreal in terms of how often I have gone there in the last few months.

[22:34:16] <tos9> tell me about it -- I left Manhattan for the first time in 3 months (but realistically 5 months) yesterday

[22:34:21] <tos9> did you know there's a whole world out there

[22:35:27] <sumanah> tos9: I believe it! I remember

[22:50:37] <sumanah> from 137, down to 80 open tickets in the SF tracker. Gonna stop for the night.

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 1st of June, 2020