PMXBOT Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 21st of August, 2015

(Back to #pypa overview) (Back to channel listing) (Animate logs)
[03:18:21] <k_sze> Our team leader did something to the dev server and now every time I create a new virtualenv I'm stuck with the global version of the av package.
[03:18:45] <k_sze> I'm not sure what he did.
[07:53:40] <ronny> k_sze: did he by chance make --site-package the default?
[07:55:22] <mgedmin> didn't very very old virtualenv versions have that on by default?
[07:57:58] <ronny> no idea
[08:25:23] <mgedmin> wheee pypi is a 503 backend read error and warehouse is a 500 internal server error for me today
[08:25:47] <ronny> epic loss?
[09:39:17] <xafer> I've an issue where the setup.py does not include (and install subsequently) the same things with a wheel and a sdist ? Any idea where I should look ?
[09:43:30] <mgedmin> link to your repo?
[09:43:55] <mgedmin> try check-manifest?
[09:44:34] <mgedmin> consider https://packaging.python.org/en/latest/distributing.html#package-data and https://packaging.python.org/en/latest/distributing.html#data-files ?
[09:47:18] <xafer> the bonus part is a package called "tests" at the root of the repo
[09:49:03] <xafer> and check-manifest only build sdist no ?
[10:00:26] <mgedmin> check-manifest will see that the sdist contains everything it should (assuming "should" == "what is in the version control system")
[10:00:48] <mgedmin> I have no tool to compare sdists with installed package data
[10:02:48] <ronny> xafer: a wheel never runs setup.py
[10:03:11] <ronny> xafer: a wheel is a onstall only package, it contains much less than a sdist
[10:03:19] <ronny> *install
[10:05:30] <xafer> I know :) My problem is with this repo: https://github.com/polyconseil/getconf
[10:05:38] <xafer> and that's what I'm getting: http://pastebin.com/TYcp7vrm
[10:06:36] <mgedmin> what do you want to be getting?
[10:06:40] <xafer> note the extras: tests/__init__.py
[10:06:40] <xafer> tests/__init__.pyc
[10:06:40] <xafer> tests/test_base.py
[10:06:40] <xafer> tests/test_base.pyc
[10:06:46] <xafer> for the wheel
[10:06:50] <xafer> but not for the sdist
[10:07:21] <mgedmin> oh, I see
[10:07:46] <mgedmin> interesting
[10:08:16] <xafer> (well, I just saw that pip used wheel caching so both installs are with wheels but you get the point ^^)
[10:08:16] <mgedmin> you have `packages=find_packages(exclude=['tests']),`, so why does bdist_wheel pick those up?
[10:08:26] <xafer> exactly
[10:11:22] <mgedmin> I cannot reproduce: if I git clone your repo and python setup.py bdist_wheel, then unzip -l dist/*.whl, I see just three .py files in getconf/ and the .dist-info directory
[10:11:41] <mgedmin> pip freeze|grep wheel => wheel==0.24.0
[10:12:03] <xafer> and setuptools ?
[10:14:33] <mgedmin> pip list|grep setuptools => 18.1
[10:17:33] <xafer> indeed, with a fresh clone and a new venv, I do not reproduce it either O_o
[10:18:18] <xafer> but still can reproduce it on the old one, I'll try to spot the difference :-|
[10:18:29] <xafer> thanks :o
[10:19:31] <evanton> I have a module and tests for it in a file called tests.py. When I run nosetest directly (with coverage support) - it shows coverage stats for my module file. But when I do python setup.py nosetests - it doesn's show coverage stats for my module, just for tests.py. What's the trick?
[10:19:48] <mgedmin> xafer, is there an .egg_info directory? it might have some stale data
[10:19:52] <evanton> s/nosetest/nosetests/
[10:19:54] <mgedmin> setuptools likes to reuse it
[10:20:34] <xafer> well I reproduced it on the new venv with old dir, so it comes from the files
[10:23:05] <xafer> and there are extra files in build/lib.linux-x86_64-2.7/ -> tests/__init__.py and test/test_base.py (from before my previous fixes I guess)
[10:23:26] <xafer> two bad this is not cleaned up :'(
[10:23:53] <xafer> deleting those fixes it
[10:25:24] <mgedmin> I guess there's a reason zest.releaser always builds releases in a clean checkout
[10:29:08] <xafer> I think wheel should recreate a fresh dir each time
[10:30:11] <xafer> if you run "setup.py bdist_wheel", add an extra file in build/lib.linux-x86_64-2.7/, and rerun "setup.py bdist_wheel" you have the extra file...
[10:31:45] <mgedmin> https://bitbucket.org/pypa/wheel/issues is where you can file an issue about this
[10:32:32] <xafer> yup, was looking through them and found https://bitbucket.org/pypa/wheel/issues/117/clean-command-doesnt-cleanup-the-build-dir ^^
[10:32:40] <xafer> I'll add a comment
[10:32:50] <mgedmin> I wonder if that's related
[10:33:02] <mgedmin> does bdist_wheel implicitly call clean?
[10:33:08] <ionelmc> i always do a rm -rf build *.egg-info
[10:33:24] <ionelmc> you never know what these tools decide to cache
[10:34:59] <xafer> mgedmin, you're right, it seems related but separate
[10:35:49] <ronny> i like how devpi clean dist/build folders before a upload command
[11:23:09] <agronholm> ronny: would you happen to know if it's possible to limit devpi access so that certain users can only download certain distributions?
[11:23:23] <agronholm> the devpi access controls documentation is "TBD" :)
[12:11:03] <ronny> agronholm: currently there are no read restrictions, i think the quickest way to get those would be to commision holger or florian
[12:11:21] <agronholm> ronny: ok thx
[15:40:07] <fladd> dstufft, sorry to bother you again about the updating the download counter, but it has been over 24 hours now and it has not been updated at all. I in the meantime downloaded via a link, and directly from the PyPi website, several times. None of those downloads has been counted. It seems that the download counter is stuck at 1285. Are there any server problems at the moment or so?
[15:45:44] <fladd> dstufft, I just realized that the problem seems to be exclusive to the XML RPC interface. I just checked the YAML URL and there the download count is at 1312.
[15:46:09] <dstufft> fladd: xmlrpc has a different cache than the JSON url
[15:46:15] <dstufft> it mifht need tweaked
[15:46:25] <fladd> dstufft, I meant JSON, indeed, not YAML, sorry
[15:47:08] <fladd> dstufft, so the JSON cache is, in general, much faster in updating? Would you advise to prefer the JSON interface to the XML RPC one?
[15:47:42] <dstufft> yea the JSON api is world's better
[15:48:16] <dstufft> the JSON api will often update immediately, or within the hour, except when a purge fails because purge retrying doesn't work atm
[15:48:48] <fladd> dstufft, cool, then I will use this instead. Thanks for the help!
[16:23:04] <fladd> dstufft, one last question: https://pypi.python.org/pypi/{package}/{version}/json and https://pypi.python.org/pypi/{package}/json show two different numbers of total downloads (for the same release; 1213 vs 1208). Which one is the correct one? And how come the difference?
[16:23:34] <dstufft> fladd: cached at different times
[16:24:08] <fladd> dstufft, so, the one with the version included is always faster, or is this just by accident?
[16:25:32] <dstufft> just by accident
[16:26:40] <fladd> dstufft, funny, just realized that even when using a different version (which will still list all release download counts) the number is different. So you are saying that over an hour or so, those numbers should be the same?
[16:27:23] <dstufft> are you familar with varnish?
[16:27:26] <fladd> dstufft, or differently asked, the are all cached with the same frequency, but at different times?
[16:27:45] <dstufft> yes
[16:27:50] <dstufft> the cache time is the same
[16:27:55] <dstufft> er
[16:28:01] <dstufft> the length of time a cached result is valid
[16:28:04] <dstufft> is the same
[16:28:14] <dstufft> if it expires it'll fall out of the cache
[16:28:20] <dstufft> until someone requests it
[16:28:22] <dstufft> at which point i'll get re-added to the cache
[16:29:29] <fladd> i am not familiar with varnish I am afraid. But if I understand you correctly, then it doesn't matter which number I use, since on average (i.e. when asking for it 1000 times), they will lead to the same result?
[16:33:20] <dstufft> fladd: yea
[16:33:45] <fladd> dstufft, okay, thanks again!
[17:20:05] <gad0lin> hey, I am downloading python packages for pip install --exists-action i --download… That works well is I do that on Linux and later also use Linux to install them. However if I fetch pkgs on OSX then fail to install on linux. Can I set some flag to pip to download linux native packages from OSX?
[17:21:59] <Wooble> gad0lin: are these binary packages?
[17:22:49] <gad0lin> Wooble: the thing particulalry fails on numpy
[17:23:11] <Wooble> gad0lin: yeah, anything with a C extension is going to need to be built on the right OS.
[17:24:38] <gad0lin> Wooble: ok, thxI will use docker to run it then
[17:59:20] <ionelmc> why would anyone do this http://blitz.works/butter/file/63d6906419ec/runtests.py ?
[17:59:36] <ionelmc> that payload contains a dict with all the code for pytest :O
[17:59:59] <dstufft> pytest supports it out of the box
[18:00:00] <dstufft> to do that
[18:00:01] <dstufft> idk why
[18:00:42] <ionelmc> woot
[18:00:45] <ionelmc> so weird
[18:00:53] <ionelmc> he has pytest 2.5 in there
[18:02:53] <ionelmc> dstufft: https://warehouse.python.org/project/codecov/ returns 500
[18:03:04] <ionelmc> actually all project pages seem to error out
[18:03:08] <dstufft> yea
[18:03:14] <dstufft> warehouse.p.o is borken
[18:03:18] <dstufft> haven't fixed it yet
[18:03:21] <ionelmc> oh
[18:03:26] <dstufft> lolpreviewsites
[18:03:31] <ionelmc> is it deployed anywhere else?
[18:04:13] <dstufft> No
[18:06:12] <ionelmc> dstufft: oook :) will you fix it soonish? :))
[18:07:08] <dstufft> Hopefully, warehouse.p.o was running old code that is broken with he new database, but the new code lacks some things we need before we can point it at the PyPI db
[18:44:36] <chaverma> trying to write settings in pip.conf, for an extra index
[18:44:49] <chaverma> my private index is running on a test port 8000
[18:44:55] <chaverma> i can't seem to pass that in via pip.conf
[18:46:31] <chaverma> is that a known limitation?
[19:48:34] <tdsmith> in this distutils-sig thread about external dependencies i'm kinda waiting for someone to propose reinventing autotools
[19:49:32] <tdsmith> it would be the right thing to do for source builds but i guess that's mostly not what they're talking about
[19:56:19] <chaverma> !logs
[19:56:19] <pmxbot> http://chat-logs.dcpython.org/channel/pypa
[19:56:39] <dstufft> tdsmith: inventing autotools ftw
[20:26:51] <xafer> chaverma, it should work, could you show your pip.conf ?
[20:30:42] <chaverma> xafer: i figured it out. the issue was complicated by my improperly specifying the trusted-host option and including the port in that value as well
[20:31:05] <chaverma> however pip install -vvv gave me no messaging about the failure of my pip.conf
[20:32:29] <xafer> what was your failure ?
[20:38:13] <chaverma> xafer: https://gist.github.com/phasetwenty/5a015781ad6ddb5d913a
[20:40:25] <xafer> mmmh what's your pip version ?
[20:40:46] <chaverma> 7.1.0
[20:49:30] <xafer> hmm you should have something like that: The repository located at mrclean.example.com is not a trusted or secure host and is being ignored. If this repository is available via HTTPS
[20:49:30] <xafer> it is recommended to use HTTPS instead, otherwise you may silence this warning and allow it anyways with '--trusted-host mrclean.example.com'. in stderr
[20:49:54] <xafer> (the part you sent to 2>/dev/null ;) )
[20:53:47] <chaverma> hmm, fair enough
[22:34:57] <ekmartin> What characters are allowed in a package name (techically, not what's recommended)?
[22:35:25] <dstufft> alpha numeric, . _ and -
[22:37:58] <ekmartin> Thanks!
[22:53:54] <doismellburning> https://pypi.python.org/pypi/0-._.-._.-._.-._.-._.-._.-0 :D