[07:50:41] <ronny> dstufft: i have an idea for replacing ez_setup with something that could even have setuptools as "setup_requires"
[07:51:25] <ronny> (the basic idea is to have a module that can download wheels into .eggs and prepend them to sys.path)
[07:52:07] <dstufft> isn't that just ez_setup.py except s/eggs/wheels/ ?
[07:52:07] <ronny> and then extend sdist, so setuptools includes the required wheels inside a sdist (or at least their md5sums/exact locations)
[07:52:27] <ronny> dstufft: well, the idea is sto have something that can even gather a recent setuptools version
[07:53:38] <ronny> dstufft: also can setuptools in future install in a way that it always activates via a pth, except for when a more recent version is already on sys.path?
[07:54:03] <ronny> the idea is to be able to have a setup.py that is always able to load a most recent setuptools from a wheel
[07:55:21] <dstufft> I think a better thing is declartive setup_requires that the installer can understand tbh
[07:56:15] <ronny> dstufft: well, writing setup_requires.txt was backed out
[07:56:40] <ronny> dstufft: bascially it seems semi-impossible to transition to it without having a sane way to obtain and import the most recent setuptools
[07:57:02] <dstufft> I'm talking about something that isn't specific to setuptools
[07:57:46] <ronny> there is no agreed format, so the next best thing would be to put it in the egg/dist info of the sdist
[08:02:57] <ronny> dstufft: but basically there is need for some kind of transition
[08:06:05] <dstufft> ronny: sure, I generally work by figuring out what the ideal end result is and trying to work backwards from there to figure out a way to make it work with the legacy
[08:07:00] <ronny> for me the firt step is to enable package authors to work with the most recent tooling, even on the older systems
[08:07:27] <ronny> you will need the most recent tools to deal with the declarative metadata at developer side and at the old consumer tools side anyway
[08:07:58] <ronny> so to me it seems the best way forward is to enable people to use the recent tools, then evolve the tools
[12:50:56] <linovia> Is the syntaxe: package==0.6.1,==0.7.0,==0.7.1 supposed to work with pip ?
[13:50:49] <xafer> I'd say it isnt a bug and falls in the 6.0 changelog: "BACKWARD INCOMPATIBLE PEP 440 is now fully implemented, this means that in some cases versions will sort differently or version specifiers will be interpreted differently than previously. The common cases should all function similarly to before."
[18:12:12] <sqwishy> I'm trying to use distutils to package a bunch of bytecode because I don't have access to the python source. Apparently using package means I'm promising a __init__.py exists, all I have is __init__.pyc and pyo
[18:12:27] <sqwishy> Can I promise that there is an __init__.pyc or pyo instead of __init__.py?