Log file Viewer

[08:15:07] <wleslie> should my setup.py attempt to detect if it's being run by pip, and optionally enable setuptools in that case?

[08:15:35] <wleslie> distutils /seems/ to work fine

[08:16:42] <[Tritium]> pip auto-patches distutils before running setup.py

[08:17:45] <wleslie> I could specify setup_requires/install_requires instead of requires if I knew they were supported

[08:18:13] <[Tritium]> You could unconditionally depend on setuptools

[08:18:59] <wleslie> yes, but I try to avoid using it myself

[08:19:43] <[Tritium]> I would bite the bullet until build and install are totally seperate. thats being worked on >.>

[08:20:18] <wleslie> seems sound advice

[08:20:33] <wleslie> thanks

[08:21:00] <[Tritium]> (context for others... I have seen the setup.py file in question.)

[08:27:52] <mgedmin> I've seen setup.py files that try to import setuptools and fall back to distutils if they get ImportError

[08:28:30] <mgedmin> I think it's unnecessary in this day and age, but it's better than using only distutils and not providing install_requires at all

[08:32:24] <[Tritium]> wleslie: also, the distutils patch still breaks if cffi isnt installed at time of running (i just retried). I dont think there is much you can do about that though

[08:33:14] <[Tritium]> wleslie: that should at least be in the except block when trying to import setuptools. That way if you have setuptools but dont have cffi, it will still work

[08:37:06] <pombreda> wleslie: I cannot fathom a good reason why you would not want to use setuptools vs the bare distutils :)

[12:45:53] <wleslie> [Tritium]: version 0.1.4 has cffi in its requires, so if you're still having problems something is definitely up

[12:47:11] <wleslie> pombreda: I've got mixed feelings about setuptools; I think entry points are great, I kind of like zipped eggs (booo?) and I really like the way it makes possible to dave several different versions of a library installed, but I had some really bad experiences with it when I first started working in python

[12:47:29] <wleslie> namespace packages are ok too, I guess

[12:48:40] <wleslie> pombreda: what I don't like is that it automatically resolves dependencies without any respect for those you already have installed. I've had applications break on me because one required version 12 of something and another required version 10. this is long before distribute, pip, and virtualenv, though.

[12:49:28] <wleslie> if those applications were using the 'require' feature of setuptools it might not have been so bad, but the reality is that stuff never worked well, which is why we now have virtualenv

[12:51:45] <wleslie> in development it's fine, but my preference is not even to have it installed in production; even if I have to hand-tweak setup.py files to make it so.

[12:55:14] <dstufft> wleslie: Yea, I'm not going to say the virtualenv way vs the setuptools way that one or the other is strictly better, they both have different trade offs. I do however think that the virtualenv way had an implementation that worked better out of the box for people and so it won

[12:56:47] <wleslie> dstufft: I know. what we've got now is better that what we've ever had in python. but I still want to make it easy for people to choose setuptools, or distutils, or pip, and a setup.py that clearly shows that all are accounted for and tested goes some way to showing that.

[12:59:00] <dstufft> wleslie: fwiw the official recommendation is to just use setuptools. You're of course free to follow that or not :) If you're not going to, probably the best way is to try and import setuptools and fall back to distutils

[13:01:47] <pombreda> wleslie: your call alright. There has been a huge amount of work put in the packaging tools ever since the setuptools road-block was removed :)

[13:03:53] <pombreda> eventually time will tell what is best.... I could envision a near future where setuptools strictly deals with building and pip with installing

[13:04:07] <pombreda> which is how I use them :)

[13:04:13] <pombreda> (and always in a venv)

[13:06:51] <pombreda> https://github.com/pypa/setuptools/issues/581

[13:08:02] <pombreda> wleslie: dstufft: this ticket makes a lot of sense to me

[13:09:29] <wleslie> indeed

[13:17:19] <wleslie> https://bitbucket.org/william_ml_leslie/python-firm/commits/cd463425b38f66d2f588d6453d58441915c6027e

[13:26:15] <pombreda> wleslie: interesting: what would be the usage of libfirm?

[13:26:58] <wleslie> pombreda: libfirm is somewhat like llvm

[13:27:32] <pombreda> wleslie: vast subject :)

[13:28:26] <wleslie> it uses a sea of nodes representation, so it has even more flexibility around instruction scheduling

[13:31:37] <wleslie> these are the current users http://pp.ipd.kit.edu/firm/Projects I've got most of a pypy translation backend, too.

[19:46:38] <appeltabak> Hi, i

[19:49:50] <appeltabak> Hi, i'm not sure if this is the right place to answer my question, but here it is: whats the way to go to download and install get-pip.pip in a one-liner in bash? i've tried 'curl -sSL https://bootstrap.pypa.io/get-pip.py | python' but that doesn't work