[Distutils] Future of setuptools and buildout

[Chris Barker]

On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth <dholth at gmail.com> wrote:

> And a while back I argued against setuptools-lite, because I thought it
> would not solve the poor extensibility problem that stems from its basic
> distutils derived design... which includes all the classes and subclasses
> that have to work together to do its thing. My own thinking is that
> setuptools is fine, except that when you need to extend it you have a big
> problem; so make it easy to replace.
>

I never had any fantasies that setuptool-lite would improve on this in a
way shape or form -- indeed, a better build system is likely to need to be
built from scratch, or on a totally different framework, anyway.


> Does pip monkey patch setuptools? I thought it just forced setuptools even
> if a package only asked for distutils.
>

good point -- not really a monkey patch, but it does force particular
configuration.


> So you are suggesting setuptools_lite would not honor the setup_requires =
> [] and test_requires = []
>

essentially, yes. Though It would be nice if that data could be available
for pip -- and I"m not sure how that is done at this point.


> and perhaps "setup.py install" would also throw an error?
>

Probably not -- but it could only install from local source -- like
distutils. Though if we could re-work it to only do develop mode and build
wheels, that may be good -- you'd need pip to install it.


> What else? I would suggest that to effectively argue the idea requires
> reading the source code and enumerating exactly which complexity goes away
> with the _lite version.
>

I don't know that reading the source is the issue -- I'm thinking entirely
in terms of stripping out the API, so there may be things that need to stay
in, but we don't expose them. though maybe even that's harder than I think.

But yes -- enumerating what would and wouldn't be supported would be a good
start. But here is the guideline:

It seems we have a (maybe vague) vision of what we want the tool ecosystem
to look like that involves separation of concerns, such that each component
is replaceable without having to change the others:

The concerns:
  - building a package
  - installing a package
  - dependency management
  - run-time version management
  - plugin handling, etc.
  - resource managment

setuptools does all of these, yes? but think of these in terms of when they
come into play:

build time:
   - building a package
install time: installing a package;
  - installing a package
  - dependency management
run time
  - run-time version management
  - plugin handling, etc.

so we have:

 - The mythical build tool
 - pip
 - maybe some of the setuptools spun off -- like pkg_resources

So why aren't we there yet?

One reason is that setuptools the only thing out there that does the
building and some of the run-time stuff. So people use it. And now you
can't replace any of it without making a mess.

However, pip_wheel have indeed addressed much of the install-time and
dependency management issues. So folks use them, and they work well.

So what problem do I want setuptool-lite to solve?

I actually have spent a lot of time using conda to do my package installing
and dependency management. So I want a way to build a python package that
JUST builds the package.

In practice, I've found (most) of the flags and work arounds to diable
etuptools "features", but really?

python setup.py install --single-version-externally-managed

Oh right, that's not enough, I need a record file:

setup.py install --single-version-externally-managed  --record record.txt

Then I want to install in develop mode:

python setup.py develop

OOPS! now it's easy installing a bunch of dependencies! arrgg!

OK, -- no-deps it is.

Google around, this kind of thing is a pain in a lot of people's butts
--even though it call all be worked around.

So my vision of setuptool-lite is that is simply does not do the things
that vision of a build tool should not do.

i.e.:

never easy-install anything!
don't try to resolve dependencies

others??

One "lite" version of setuptools that I personally think would be cool
> would be pkg_resources as a separate package on pypi. Setuptools would
> require it as a dependency.
>

Yes, I'd love to disable pkg_resources too, but couldn't until it was spun
off.

In fact, years ago, long before pip, setuptools drove me crazy with how it
combined run-time, build time and intall time stuff. A serious problem when
I wanted to bundle something up with py2app (or py2exe, or...).

So what would be accomplished?

package builders could simply put:

from setuptools_lite import setup

(etc.)

and then their user would never accidentally easy install anything, etc.
And it would serve as documentation / notification if a user was using a
what-should-be-deprecated feature.

By the way, this is totally acknowledged to be a hacky, temporary mess that
might only help a bit to get us closer from being locked into setuptools.

(though maybe it would be a place to work through some of the issues with a
build API)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160818/920b832f/attachment.html>