> Unsure, I'd have to see a more concrete proposal. I don't particularly like > the idea of partitioning what developers do from what users do, since then > developers won't be testing the user packaging in the course of normal > development.
This is a really good point. It is the exact opposite of what I wrote earlier in this thread, which was that I want to enable people to have a setuptools-free way of doing things without disabling other people having a setuptools-included way of doing things. I guess what it boils down to is that Brian isn't going to be that developer. The one who does things the same way that users do, so that he's always experiencing the user-facing code. Other developers might, though! I looked for Brian's "unsuck packaging" branch today on github in order to make a proof-of-concept hack to support Brian (and gdt, etc.) and setuptools-lovers in the same codebase, but I couldn't find it. I did find a whole lot of other exciting branches that Brian has been writing patches for but hasn't mentioned that he is doing so! (And yes, I'm using "setuptools" here as a shorthand for the widely-used Python-community way of doing things, with automatic dependency resolution, auto-cross-platform stuff, integration with other Python tools like pip, virtualenv, pypi.python.org, crate.io, etc. I don't mind if we lose the actual *setuptools* source code while retaining all of that functionality. I doubt that it is currently possible. Maybe it will be possible in the future! Also, did you know that control of the name "setuptools" in the Python packaging namespace has been transferred from original setuptools developer Philip J. Eby to the distutils/distribute/whatever team?) Regards, Zooko _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
