Log file Viewer
#pypa logs for Friday the 4th of September, 2015
[00:18:17] <triogenes> my CI builds use a pip install of my package which means i get a "new download" on pypi every time a build happens
[13:07:44] <natim> But apparently, pypy installation also try to use this wheel which doesn't have the pp2 tag
[13:21:54] <ronny> natim: sounds like a bug, the cpython specific one should use cp... - pypy should try the py2/3 ones as well
[13:23:59] <natim> Note that in my case I don't have the same dependencies for pypy and cpython2/3 so that py2-py3*.whl doesn't work with pypy
[13:25:55] <natim> Yes but this line of code doesn't handle them: https://bitbucket.org/pypa/wheel/src/f746a01eab7a673cb628a52f99c129d0d5741bcf/wheel/bdist_wheel.py?at=default#bdist_wheel.py-99
[13:28:16] <ronny> natim: you can use extras_require={":implementation_name == 'thenamepypyuses'": ['needed_by_pypy']}
[13:31:31] <natim> ronny: apparently https://bitbucket.org/pypa/wheel/src/f746a01eab7a673cb628a52f99c129d0d5741bcf/wheel/bdist_wheel.py?at=default#bdist_wheel.py-113:114
[13:33:56] <ronny> then you will have one wheel and it will use different dependencies based on the implementation name
[13:44:52] <natim> ronny: I have tried https://www.python.org/dev/peps/pep-0496/#examples whithout success
[13:55:14] <natim> ronny: I could use python_implementation to generate the build but then when trying to install I get NameError: global name 'python_implementation' is not defined
[13:56:48] <ronny> natim: hmm, this is costing too much time for you, you mgiht want to run 2 builds, one with pypy passing the pp version tag and one for cpython pasing the cp version tag
[14:00:33] <ronny> natim: the problem is that environment markers are not yet widely and correctly implemented
[14:02:00] <ronny> natim: use python setup.py bdist_wheel --python-tag cp2.cp3 for cpython and pypy setup.py bdist_wheel --python-tag pp2.pp3 for now
[14:59:13] <moldy> i am aware of https://github.com/pypa/pip/issues/1668 but it's a little hard to see in which direction things are moving right now
[15:35:07] <dstufft> moldy: the current state is we still plan to default to --user when not as root but I haven't had time to work on it more and nobody else has picked it up
[15:39:03] <moldy> dstufft: what about the anti-usecase of people breaking their systems by running "sudo pip install foo"?
[15:40:41] <moldy> the problem is, it will not fix all the broken documentation on the web that explicitly tells people to run sudo pip install
[15:40:54] <dstufft> we're not going to prevent people from running pip as root, it would break a lot of people's use cases and it's not an unreasonable use case. It's often times perfectly fine to install things using pip.
[15:41:18] <agronholm> pip install --user places the scripts in a directory which is NOT on the PATH by default
[15:41:32] <moldy> i'd bet that 99% of the times, it's not a legitimate usecase, just somebody not knowing he is about to break his OS
[15:42:58] <dstufft> it's a perfectly reasonable thing to install into /usr/local with pip and if that breaks things that's a failing of the toolchain not of the person invoking the command
[15:43:46] <moldy> but the current reality is that people read instructions on how to install X and 2 minutes later their os is broken.
[15:46:13] <moldy> given the fact that python is an all-purpose language, a very wide range of tools can in principle be affected by this
[15:47:16] <dstufft> My plan for that is to standardize the patches that Debian has which has a different directory for "vendor" installed packages and "administrator" installed packages, and for something as critical as a package manager they'd use a new flag that I plan to add that says to exclude everything but the vendor packages
[15:48:28] <dstufft> But what you're asking is the equivilant to making it impossible to run ``make install`` into /usr/local too, people can do that and break their system just as easily if they aren't careful about what they install.
[15:52:05] <dstufft> Another item I plan on adding is adding a file to the python metadata, INSTALLER (or something like it) which will be a file that tells pip what tool was used to install a particular library and if it's a system package manager then pip won't uninstall it (but, in combination with the vendor patch) it will be willing to install into the site-packages instead of vendor-packages, but also importantly it will likely treat the already installed
[15:52:05] <dstufft> version as a "use this unless it doesn't match our required version" instead of "try to upgrade to the latest version"
[15:57:07] <moldy> personally i don't like all this complexity and special-casing and tools reading other tools' stuff, but ah well :)
[15:58:56] <dstufft> I happen to think that the old model of what an OS is is broken and doesn't make sense anymore, but I don't have the energy to fight with the distros to tell them that the things they picked in the 90's doesn't make sense in 2015.
[16:01:16] <dstufft> I don't even care about unifying their package tooling, but I think a lot of problems come from the fact that distros have pacakges which are designed to install *system utilities* but they make these system utilities available in non system use cases
[16:01:39] <dstufft> take Python, Python exists so that system tools written in Python can exist, not so that random developers can install stuff into it while developing
[16:01:57] <dstufft> so don't put ``python`` on the default path, hide it somewhere that's for system use only
[16:02:13] <moldy> personally i just use virtualenv for everything that is not part of the base os, but most newbies don't
[16:02:43] <dstufft> (IOW, I think that idea of what OSX is doing with OpenSSL in El Capitan is the right way, OpenSSL is there, but it's not for you it's for the system and you can't compile against it really without hacking up your system)
[16:04:53] <moldy> agronholm: it is in python3, but you still have even high-profile packages like django telling people to run "sudo pip install django" in their installation docs :/
[16:04:57] <dstufft> I mean, it's still butchered because distros love applying random patches to things
[16:05:33] <dstufft> Step 1: to Debugging why pip isn't working how the docs say is to uninstall the distro version and install a real version
[16:13:30] <agronholm> is there a tool that would let me write a single spec file and would spit out the proper rpm, deb or whatever
[16:17:07] <moldy> agronholm: there are various tools that try to do this. "fpm" would be one of them that i happen to use
[16:19:37] <doismellburning> agronholm: it doesn't quite do what you're talking about though; I was writing a wrapper that would have, but then Docker happened
[20:45:36] <transit> I've been trying hard to get a package's dependencies from a private (institutional) subversion repository installed when the package is installed, I can install via pip but could not get it done with dependency_links. Here's what I came up with: https://dpaste.de/tnot Comments?
[20:47:29] <xafer> if using dependency_links in your packages, you might need the --process-dependency-links option when invoking pip install
[22:48:38] <mathieui> is there a way of specifying a dependency in a requirements.txt without triggering the build action?
[22:49:12] <mathieui> because for some things (e.g. cython), building takes a long time, even if it’s already usable without it
[22:52:56] <dstufft> mathieui: Not really, but as of pip 7 if you have ``wheel`` installed it'll cache a built wheel and reuse that in future installations
[22:56:06] <mathieui> another question then, is there a way to mix system packages and venv-installed packages?
[23:00:08] <mathieui> yes, but iirc if you do a pip install -r requirements.txt and one requirement is in a different version on the system, it will fail
[23:05:03] <moldy> if the requirements.txt specifies foo==1.0 and the system has 0.9 or 1.1, what do you expect?
[23:13:10] <mathieui> theoretically, a virtualenv could have a dedicated site-packages directory, and still configure $PYTHONPATH to load modules from the system-wide directory if they are not found in the venv-specific one, right?
[23:17:12] <moldy> "Give the virtual environment access to the global site-packages." isn't that what you want?
[23:20:31] <mathieui> Yes, but I want to install things in my venv, which isn’t possible if I enable --system-site-packages
[23:23:09] <moldy> mathieui: and then i activate the virtualenv and install stuff into it. works fine.
[23:25:56] <moldy> of the python3 standard distribution, which means that nobody uses it so it doesn't get tested ;)
[23:28:35] <moldy> mathieui: that's a fine decision, so you chose to rather be the first one to run into certain bugs. cool :)
[23:29:24] <moldy> most people who develop on python3 are probably like me and still use virtualenv rather than pyenv, just because it works
[23:30:54] <moldy> i was told ``that virtualenv -p`` is broken, but i will only switch after i actually hit a problem with it in practice
[23:32:06] <moldy> same thing about --relocatable, btw. i read it's evil and broken, but as long as it works for me, i am happy to use it :p
[23:33:00] <moldy> chances are that by the time you switch away from it, somebody has fixed the problem
[23:36:34] <moldy> jessamynsmith: of course, they are probably still right. but well, every software is broken in some way.
[23:37:09] <jessamynsmith> and, I don't know, but I feel like we are a long way from making self-healing, self-replicating machine life
[23:37:34] <moldy> maybe i am getting old, but i tend to be pretty conservative nowadays. if it isn't broken in a way that affects me, i don't care.
[23:39:25] <moldy> and if "intelligent life" (whatever that means) would be a good idea is another story