Log file Viewer
#pypa logs for Monday the 2nd of May, 2016
[01:34:00] <Vye> Is it possible for pip to be installed without a complete distutils module built into Python?
[01:39:49] <Vye> tdsmith, No, Splunk forces you to use their pre-packaged interpreter (or write a wrapper script that invokes yet another Python).
[01:40:35] <Vye> I wanted to have an optional pip-managed packages directory that scripts could add to the sys.path but their distutils is incomplete.
[02:08:05] <glasnt> I keep forgetting that setup.py allows arbirary python code (it's a .py for a reason)
[07:42:37] <ionelmc> Vye: you can always use a different interpreter to download packages, it'll be fine if you don't install any c extensions
[12:15:10] <vincentll> why does "python setup.py bdist_wheel" adds ".dev1" to my package version? (0.1.1 -> 0.1.1.dev1)
[12:17:32] <ronny> vincentll: its impossible that this happens in a plain setuptools context, so please tell/show what you actually do
[12:18:46] <vincentll> ronny: I'm making a package, the setup.cfg file has "version = 0.2", then I build the package with "python setup.py bdist_wheel" and the package is named "package...0.1.dev1..."
[16:30:49] <boegel> apollo13: I really don't understand why the download URLs were changed on the production PyPI... but I'm already discussing that with dstufft in #python :)
[16:37:26] <apollo13> boegel: and well, comments like yours on bitbucket are not really helpful either to be honest
[16:37:46] <apollo13> it is interesting how people just take pypi and everything around it for granted
[16:41:26] <boegel> apollo13: I'm just relaying what a lot of people think... a change like this is very hard to explain to people
[16:42:20] <boegel> apollo13: to me, stating "patches welcome" after just breaking production to make pre-production stable, and then implementing a workaround only in pre-production, is hard to justify
[16:44:11] <boegel> apollo13: that being said, I'm willing to do an effort to see if I can help in restoring the old URL format by implementing a mirror thing, like was implemented for warehouse...
[16:44:24] <apollo13> boegel: so you are saying dstufft should fix a system no one wants to touch just because some people are afraid of change?
[16:44:57] <apollo13> boegel: mhm, feel free -- I tried diving into the old pypi code once and ran away, I hope you have more luck
[16:46:11] <boegel> apollo13: well, seems like *a lot* of people are being hit by the URL change too, so we're just replacing one problem with another here...
[16:47:07] <apollo13> while I agree that cool uris should not change, I find it odd that people complain about url changes in a website which isn't "theirs" -- using the api instead of undocumented urls would have never led to this problem in the first place, no?
[16:48:04] <boegel> apollo13: a simple easy-to-derive URL like the one that was in place should've been part of the API all along, it's short-sighted to just point to a PEP and say "not our fault that you weren't aware"
[16:48:45] <apollo13> boegel: imo not more short-sighted than using a package repository by just guessing
[16:49:18] <apollo13> if I would develop code like that (ie run against a system without checking for a proper api first) our customers would probably kill me :p
[16:49:38] <boegel> it's just so straightforward, so people assumed it was OK to do it (which makes a lot of sense imho)... it's just the KISS principle
[16:50:19] <apollo13> I understand that, what I don't understand is that people are so upset if their assumptions turn out to be wrong -- but I guess that is just a point of perspective
[16:50:54] <boegel> it's because it doesn't make sense not to consider the previous URL format as a part of the API, imho
[16:51:17] <boegel> it feels like looking for excuses, and throwing your hands up and going "not our fault"!
[16:53:32] <boegel> so, say I'd want to take a stab at 'fixing' this... besides figuring out the PyPI code, what else would I need to do to test a fix I may come up with? set up a PyPI mirror of sorts?
[16:54:14] <apollo13> or directly on pypi since you probably cannot break it "more" (sounds horrible I know)
[16:54:17] <dstufft> If legacy PyPI didn't make me want to quit anytime I looked at it for more than ~5 minutes I'd probably just fix it, but it's really just me keeping this running (and it's like... 3/4 of a billion requests in the last 7 days and 80TB of bandwidth used and I'm struggling to keep the plates even barely spinning)
[16:55:27] <dstufft> boegel: there's a database dump in the warehouse repo, with some judicious use of commenting out code you can get PyPI running locally against that DB (though you might need to checkout the warehouse code and run the DB migrations in there against it, I forget if there are any mandatory migrations since I last took a snapshot)
[16:56:57] <boegel> dstufft: I trust PyPI maintainers would have an easier way to testing a proposed change?
[17:00:25] <dstufft> boegel: this is one of the many reasons Warehouse exists tbh. It's a huge pain to run the code in anything resembling a production deployment. Half the time I don't even try to run it locally and I just push straight to prod
[17:01:31] <dstufft> (Note, that's not all the recorded errors, just the ones that would fit on screen)
[17:03:56] <boegel> dstufft: I'm not debating whether Warehouse is not worth the effort, it obviously is
[17:07:12] <boegel> any idea why the 'old' download URL seems to work fine for old package versions? e.g. https://pypi.python.org/packages/source/p/python-dateutil/python-dateutil-2.5.0.tar.gz works, https://pypi.python.org/packages/source/p/python-dateutil/python-dateutil-2.5.3.tar.gz doesn't
[17:23:40] <boegel> dstufft: well, since there's a mirror workaround in place in Warehouse, that doesn't matter, right?