Log file Viewer

[00:19:10] <mitsuhiko> dstufft: in case you care. i get 500s on submitting packages at the moment

[00:19:14] <mitsuhiko> archives seem to show up anyways though

[00:19:16] <mitsuhiko> very consistent

[07:59:26] <ronny> aviau: i see, thats hard to do by design, why woudl you wana do that?

[10:49:16] <DRMacIver> I was seeing this earlier: https://travis-ci.org/DRMacIver/hypothesis/jobs/102127073#L139 it was solved by clearing the travis cache, but it recurred until I did. Is it a known issue / deliberate design choice that pip doesn't detect corrupt cached data and if not would you like me to file a bug about it?

[11:14:06] <DRMacIver> I don't see anything in the issue tracker, so I'll file a bug.

[11:18:48] <mgedmin> there was one issue about wheel cache poisoning due to dynamic computation of, e.g., install_requires in setup.py

[11:19:07] <mgedmin> it was closed because the issue was fixed in git -- but of course since there were no pip releases since then, users still suffer

[11:22:38] <DRMacIver> It doesn't look like this one has ever had an issue filed about it

[11:22:55] <DRMacIver> And I don't have a simple repro so I can't test against git.

[11:23:04] <DRMacIver> So I've filed all the information I have at https://github.com/pypa/pip/issues/3359

[11:30:12] <mgedmin> ah, http cache, not wheel cache

[11:31:10] <mgedmin> could be https://github.com/ionrock/cachecontrol/issues/83 ?

[12:34:49] <DRMacIver> mgedmin: Ah, you might be right. I'll add a comment to the issue linking to that.

[14:31:00] <nicksloan> does pip cache the absence of a package?

[14:37:12] <brechtm> hi

[14:37:28] <ionelmc> nicksloan: i don't think so

[14:38:26] <brechtm> Should I avoid namespace packages in today's packaging ecosystem? (can't seem to find a clear answer on this on the web)

[14:39:18] <brechtm> The Python Packaging User guide doesn't even mention them

[14:40:02] <brechtm> I want to provide an extension system for my package. I was thinking: namespace packages + entry points

[14:43:46] <nicksloan> brechtm: I use namespace packages for my stuff, and it seems to work fine.

[14:43:51] <nicksloan> there are some quirks though

[14:44:20] <nicksloan> brechtm: though why not just use entrypoints? Do you care what people name their packages?

[14:44:21] <aviau> ronny: The script is a cgi script. So it belongs in /usr/share/package. However, it has other useful functionalities in the command line.

[14:45:01] <brechtm> I understand there were some incompatibilities between pkgutil and setuptools implementations? But I guess we can assume everyone has setuptools installed nowadats...

[14:45:15] <aviau> I dont really mind swapping things around, installing it in usr/local and symlinking in usr/share/package. None of the two are easy to do.

[14:45:19] <brechtm> nicksloan: I guess that will be the safest way to go indeed

[14:46:32] <brechtm> I suppose I can suggest using <project>lib_<extension> package names

[14:46:40] <aviau> ronny: I tried clever hacks, like installing a relative symlink using data_files, but setuptools wont install symlinks!

[15:07:50] <ionelmc> aviau: why don't you use a os package? if you need to be so specific then python packages are wrong choice

[15:08:06] <ionelmc> eg, rpm or deb

[15:08:46] <aviau> ionelmc: We do have an os package. I am a Debian Developper actually, and I'm working with upstream. But upstream still wants people to be able to install with the setup.py

[15:11:31] <ionelmc> aviau: maybe the upstream wants something intractable

[15:12:56] <Wooble> CGI scripts being distributed to more than 1 legacy machine sounds scary. :/

[15:13:53] <aviau> Wooble: Why?

[15:14:58] <Wooble> because it's not 1995?

[15:15:30] <ionelmc> aviau: it means you're serious about it, that's what's scary. if it's a single machine it's easy to dismiss it as a toy project

[15:16:40] <aviau> Lol. I don't see how they are any less secure/useful than an application server.

[15:18:19] <aviau> I'm not here to send you guys on a witch-hunt.

[15:19:37] <ionelmc> damn it, but i just cleaned up my bloodied pitchork!

[15:24:01] <ionelmc> brechtm: just an observation: there are some packages on pypi that live in the "setupext" namespace for some reason. all fine and dandy but in a freaky coincidence matplotlib has a setupext.py in its sdist. this makes matplotlib unbuildable if you got any of those namespace packages installed.

[15:24:38] <ionelmc> ns packages can complicate things a lot. you better make sure no one else is gonna use them for other purpose

[15:24:42] <brechtm> ionelmc: thanks, won't use that one

[15:25:09] <brechtm> I'll probably avoid namespace packages altogether

[21:48:33] <nZac> What is the reason to exert this much effort to get a version number? https://github.com/zzzeek/sqlalchemy/blob/master/setup.py#L110-L116

[21:52:57] <tdsmith> https://packaging.python.org/en/latest/single_source_version/

[21:54:07] <nZac> tdsmith: it seems like just importing package.version with a variable called version works. Why not do that?

[21:59:20] <tdsmith> i don't remember, but the important thing is that you can't import any of your dependencies while you're figuring out the version; maybe there's an implicit evaluation of __init__.py there

[22:00:43] <nZac> tdsmith: Thanks. You are right #6 addresses this.