Log file Viewer
#pypa-dev logs for Monday the 7th of October, 2019
[15:35:36] <sumanah> btw EWDurbin woodruffw I'm here in case you want to diagnose my cursed pybabel problems here
[15:36:19] <EWDurbin> sumanah: i saw in another issue that you had run some `pip intall -U` or upgrades... you might want to `make purge` before trying again
[15:37:33] <sumanah> EWDurbin: just ran `make purge` and then `make build` on master and then `make build-mos` and got the same error again
[15:39:30] <EWDurbin> the logs you added to 6780 seem to indicate some issues with the pip install step.
[15:41:04] <EWDurbin> i'm confused as to why `/home/sumanah/.virtualenvs/Mon-Oct-7-2019-PyPI-Test/lib/python3.7/site-packages` is coming into play
[15:42:21] <sumanah> (right, Freenode tried to interpret that as a command when it was on its own line)
[15:42:26] <EWDurbin> so it looks like you've created a virtualenv that you've already activated before running make?
[15:43:08] <EWDurbin> though i'm really not sure why our make tasks are installing stuff into that venv versus .state.env
[15:43:35] <sumanah> I've been using a virtualenv to cordon off Warehouse development from other stuff for years so I didn't realize this wasn't going to work anymore
[15:44:12] <EWDurbin> all the make tasks that currently run locally rather than in docker should be doing that themselves.
[15:44:59] <sumanah> so this means installing docker-compose globally instead of in my virtualenv -- ok
[15:54:16] <sumanah> sangy: https://github.com/pypa/warehouse/issues/6780#event-2692271263 has more details
[15:55:54] <sangy> ah, it's more of a conflicting deps issue between -compose and the rest of the toolchain then?
[15:57:22] <sumanah> not sure what you mean sangy ..... I personally was using a virtualenv to avoid having to install docker-compose globally, and now have just gone ahead and installed globally ..... I don't know what caused this particular glitch
[16:01:31] <sangy> so docker-compose is a python script that has strictly-versioned requirements. Somewhere else in the babel toolchain there's a =< that adds a conflict on the deps
[16:01:50] <sangy> installing it globally just makes setuptools not be aware of that strict versioning on docker-compose
[16:05:53] <sangy> i.e., https://github.com/docker/compose/blob/1.24.1/requirements.txt#L20 can't agree with https://github.com/pypa/warehouse/blob/master/requirements/main.txt#L504
[16:25:46] <sumanah> EWDurbin and woodruffw are more skilled than I am at this bit of things so I'll let them check that out, sangy - thanks
[16:27:07] <sangy> oh np! I do think that documenting it is a great path forward though. The other alternative of tracking the docker-compose version may be more painful and unrewarding :)
[17:03:48] <pombreda_> sangy: re "this is why I personaly don't like lockfiles" --> the issue is more about application deps vs. library deps. Here the issue stems that compose is an app not a lib.... so installing as a lib (e.g. in your venv) is likely a problem
[17:04:22] <pombreda_> e.g. lockfiles are needed for apps and possibly problematic for libaries IMHO ;)
[17:10:05] <sumanah> btw if other people could take over mentoring this new contributor https://github.com/pypa/warehouse/pull/6784 I'd appreciate it
[17:16:01] <sangy> pombreda_: overall I like that heuristic, but in reality the line between libraries and apps is rather blurred. I also think that there is absolutely 0 thought behind why requests 2.22.0 is needed other than "this is what probably got pulled in by some dep so I need it"
[17:16:45] <sangy> people keep thinking that dependency management and packaging is an afterthought and that a tool will just do it right. Now we have a bunch of conflicting lockfiles lying around and people thinking that version bumps with dependabot are the future
[17:42:29] <pombreda_> sangy: re "in reality the line between libraries and apps is rather blurred" --> very true.. and I think the latest Golang go module thingy (or is it npm?) has this approach: use the lock file you provide, but ignore the lockfiles of your deps at full deps. (and FWIW, this is also the Python way more or less when requirements and setup.py are used "correctly"
[17:43:18] <pombreda_> sangy: re: " Now we have a bunch of conflicting lockfiles lying around" --> yeah that's sad :|
[17:50:56] <pombreda_> One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package.
[17:52:01] <pombreda_> basically it means use the lockfile at the top level, and use the (likely less locked, lax) requirements specified in the manifests otherwise
[17:52:49] <pombreda_> which kinda means: use setup.py for libs and locked requirements.txt for apps (assuming the top level is an app... and if you require something else it is a "lib")
[18:46:53] <sangy> pombreda_: yeah that's something we struggled a little bit with in-toto. We ended up not locking the requirements on setup.py and locking on the ci and dev requirements
[18:51:03] <pradyunsg> sangy: that sounds like the right way to go about it -- I wish everyone who does Python packaging reads https://caremad.io/posts/2013/07/setup-vs-requirement/
[18:52:45] <sangy> pradyunsg: it was actually one of our references in here \o/ https://github.com/in-toto/in-toto/pull/294#issue-295770914
[18:54:10] <pradyunsg> sangy: to be abundantly clear, I wasn't implying that *you* specifically didn't know about it.
[19:55:46] <sumanah> EWDurbin: so https://github.com/pypa/warehouse/pull/6747 -- it might not be mergeable! in which case please feel free to closeit
[19:56:15] <sumanah> but if it is -- I am writing my final community report on the a11y and i18n work so it would be _neat_ to say "and you can try PyPI in Portugese now"
[19:56:41] <EWDurbin> thanks sumanah! i'm going to spend some time late this week trying to figure out the best way for us to handle building translation files from source