Log file Viewer
#pypa logs for Wednesday the 19th of August, 2015
[00:19:47] <preyalone> could we make Author/Owner clickable hyperlinks to user pages, to make it easier to search for / list packages by author?
[02:04:32] <marbar> i have a question about .pypirc configuration (https://docs.python.org/3/distutils/packageindex.html#pypirc)
[02:04:51] <marbar> the format specified on that official python website doesn't seem to be working for me
[02:05:33] <marbar> and "python setup.py sdist upload" still gives me "You must be identified to edit package information"
[12:17:15] <frankier> Does anyone know how in a setup.py I'd require django-formtools if Django>=1.8, otherwise not require it?
[12:17:37] <frankier> Does setuptools allow for these type of requirements? Or is there another way I can deal with this issue?
[12:21:19] <ronny> frankier: no, thats not yet possible, its questionable if it would be supported anytime soon
[12:22:52] <frankier> mgedmin, The problem is then Django < 1.7 can't be supported since formtools requires a newer version in its setup.py. I think I can work around it by shelling out, or just drop compatibility with older versions. Good to know there's not a better way.
[13:03:47] <pjdelport> frankier: The most pragmatic solution if you're developing a library is probably to just document it.
[13:04:15] <pjdelport> Leave it up to leave packages to depend on the appropriate version of Django, and pull in django-formtools based on that.
[13:09:46] <frankier> pjdelport, Actually, it involves the test suite really, since it's just to test interoperability, but you saying that makes me realise I can just put it in tox.ini/the docs. Way less hassle about than importing pip and messing with importlib.
[13:10:16] <pjdelport> Ah, yes, that's definitely the kind of thing that belongs in tox.ini, for the relevant env definitions.
[15:57:55] <evanton> trying to setup nosetests setuptools command in a virtualenv. this is my setup.ini: https://dpaste.de/q09Q nose is installed in the virtualenv, 'nosetests' works, but 'python setup.py nosetests' says invalid command. what am I missing?
[16:18:15] <ronny> evanton: also note, that for nose one usually uses a colector class plus setup.py test
[16:18:45] <evanton> ronny: what do you mean by "setup command class"? I am not familiar, just been following the nose docs
[16:19:00] <evanton> well, I have heard good things about py.test, I've tried it, but I like nose more
[16:20:37] <evanton> it suggests having a [nosetests] section in setup.ini, which I did, as the pastebin link in my question shows
[16:27:36] <evanton> Wooble: my apologies. nose docs say setup.cfg, I have a setup.cfg. what I said above about setup.ini was a typo. this whole thing has got me dizzy, sorry
[16:31:59] <evanton> I found this https://stackoverflow.com/questions/14969173/why-do-i-get-the-error-invalid-command-nosetests-when-i-run-nosetests-from-my
[16:33:11] <evanton> Wooble: I have "from distutils.core import setup" there, so I assume the answer is "no"?
[16:34:34] <evanton> Wooble: IIRC I used the python docs to teach myself how to write setup.py, can you suggest me a link to read more about using setuptools?
[16:35:28] <evanton> thanks for your patience, I'll read that, then try to switch to setup from setuptools and will be back if it still won't work
[16:45:37] <evanton> and I had absolutely no reasons to suspect that was the problem, before I only used setup from distutils and it used to build tarballs just fine. I never ran tests with it and never used a virtualenv
[17:35:22] <evanton> setuptools question: I have a setup_requires line in setup.py, it tries to fetch requirements from pypi. how do I tell it to not go to pypi at all, but instead fetch stuff from a custom location that I provide?
[17:40:14] <pjdelport> evanton: Give "pip install" a different --index-url, or use a combination of --no-index and --find-links
[17:41:09] <pjdelport> If you really want to put it in your setup.py, you can do roughly the same thing as --find-links with dependency_links and --process-dependency-links
[17:41:40] <evanton> pjdelport: here is a bit more context. all this happens inside a virtualenv. I have a pip.conf there that looks like https://dpaste.de/BefW
[17:42:56] <pjdelport> Ah, yes, that happens at the setuptools level, before pip and virtualenv really.
[17:43:40] <pjdelport> The easiest way to deal with that in my experience is to manually pre-install the setup_requires dependencies into the virtualenv first, with pip.
[17:44:43] <pjdelport> Assuming you have a small and static set of setup_requires, that should remain pretty manageable.
[17:59:07] <evanton> pjdelport: bah, pip install coverage still works, even if I don't have it in my local pypi repo. how do I tell pip to not fall back to pypi at all? isn't having just a custom global index_url in pip.conf enough?
[18:00:32] <pjdelport> Maybe that index_url actually needs to specifically be in an [install] section, rather than [global]
[18:03:14] <evanton> if I add no-index = 1 to pip.conf, it doesn't even go to my custom index at all
[18:07:45] <evanton> pjdelport: for which setup? my original one with custom index_url in [global] and without no-index?
[18:09:49] <evanton> I just don't want it to fall back to pypi when it doesn't find stuff in my local repo
[18:12:08] <evanton> pjdelport: oh, I think I found the problem, it's my local pypiserver instance that is doing the fallback. I see it has an explicit command line option to disable it
[18:15:10] <evanton> pjdelport: yes, that was it. running pypi-server with --disable-fallback works properly