[tahoe-dev] suggestions for the next release

[Zooko O'Whielacronx]

> 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