Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #8136

Re: Amend Debian Python Proposal to Include More Python Metadata?

From Scott Kitterman <debian@kitterman.com>
Newsgroups linux.debian.maint.python
Subject Re: Amend Debian Python Proposal to Include More Python Metadata?
Date 2016-01-23 01:20 +0100
Message-ID <qTU5Q-3am-5@gated-at.bofh.it> (permalink)
References <qTopk-6qy-11@gated-at.bofh.it> <qTSx5-20U-29@gated-at.bofh.it> <qTSQp-28S-7@gated-at.bofh.it> <qTT06-2t8-17@gated-at.bofh.it> <qTTjs-2Bp-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On January 22, 2016 6:27:08 PM EST, Donald Stufft <donald@stufft.io> wrote:
>
>> On Jan 22, 2016, at 6:04 PM, Scott Kitterman <debian@kitterman.com>
>wrote:
>> 
>> On Friday, January 22, 2016 05:50:13 PM Donald Stufft wrote:
>> ...
>>> We already have an option like this, the —root option which will
>just append
>>> a different prefix to all of the installation paths. So essentially
>instead
>>> of invoking ``python setup.py install —root /tmp/something/`` which
>is what
>>> I think you’re doing now, you’d do ``pip install —root
>/tmp/something/
>>> —no-deps .`` and it’d just work similarly to what you have now,
>except pip
>>> would be responsible for interacting with the Python build system.
>> ...
>> 
>> Why would pip interacting with the Python build system instead of
>setuptools
>> be better?
>> 
>> Scott K
>
>setuptools *is* the build system right now (or distutils if you’re
>still using
>that). So the benefit to Debian right now would be: We maintain the
>distutils/setuptools hacks to make them suck less so you don’t have to!
>
>Longer term, we want to enable people to go hog wild and invent their
>own
>build systems instead of trying to do it all one size fits all with
>everyone
>miserable because it doesn’t solve anyones problems nicely. At that
>point the
>benefit to Debian becomes that instead of having to implement the
>standard
>build tool interface that these tools implement (Which will most likely
>be
>geared towards produces wheels, not towards putting files on disk in an
>installed location) Debian can just let us maintain that bit of code
>too.
>
>Of course, if Debian would prefer to interact directly with these
>tools, it’s
>totally fine to do that. The whole point of us doing this work and
>trying to
>define formats and APIs and not bless implementations is so anyone who
>wants
>to can slot in their own tool in the process instead of being forced to
>use
>some blessed tool.

You probably expected something like this back, but here goes anyway...

The Zen of Python says, among other things, "There should be one-- and preferably only one --obvious way to do it".  Build systems seem to me like a great place to apply that.

Build system proliferation is a nightmare.  In the last several months I've gone through roughly all of the several hundred packages in the Debian archive that build (or were packed like they build) compiled code (e.g. python C extensions, library bindings, etc.).  I was working on two goals:

1) Making sure they built with python3.5

2) Adding support for building with multiple python3 versions

For the former, the issue were sometimes buil system related, but for the latter that was almost always the case.  When packages used setup.py (and it made no difference if it was distutills or setuputils) it was virtually always easy.  For anything else ranged from moderately complex to not worth the trouble.

For the things I need it for in the distro, setup.py (with the changes we've made) works really well.

Why do we need a bazillion options for Python build tools?  To close with another quote from the Zen, "Special cases aren't special enough to break the rules."

Scott K

P.S. I worry about having to go through waf again [1].  That was painful.

[1] https://lists.debian.org/debian-dak/2012/01/msg00009.html

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-21 15:30 +0100
  Re: Amend Debian Python Proposal to Include More Python Metadata? Paul Tagliamonte <paultag@debian.org> - 2016-01-21 15:50 +0100
    Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-21 16:10 +0100
      Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-21 17:00 +0100
  Re: Amend Debian Python Proposal to Include More Python Metadata? Piotr Ożarowski <piotr@debian.org> - 2016-01-22 16:40 +0100
    Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-22 17:00 +0100
      Re: Amend Debian Python Proposal to Include More Python Metadata? Piotr Ożarowski <piotr@debian.org> - 2016-01-22 17:20 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Paul Tagliamonte <paultag@debian.org> - 2016-01-22 17:50 +0100
          Re: Amend Debian Python Proposal to Include More Python Metadata? Piotr Ożarowski <piotr@debian.org> - 2016-01-22 18:20 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-22 18:00 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Piotr Ożarowski <piotr@debian.org> - 2016-01-22 18:40 +0100
      Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-22 18:00 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-22 18:20 +0100
          Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-22 18:50 +0100
            Re: Amend Debian Python Proposal to Include More Python Metadata? Fred Drake <fred@fdrake.net> - 2016-01-22 19:40 +0100
              Re: Amend Debian Python Proposal to Include More Python Metadata? Fred Drake <fred@fdrake.net> - 2016-01-22 19:50 +0100
                Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-22 20:00 +0100
              Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-22 19:50 +0100
      Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-23 09:20 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-23 09:30 +0100
  Re: Amend Debian Python Proposal to Include More Python Metadata? Barry Warsaw <barry@debian.org> - 2016-01-22 23:40 +0100
    Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-23 00:00 +0100
      Re: Amend Debian Python Proposal to Include More Python Metadata? Barry Warsaw <barry@debian.org> - 2016-01-23 00:10 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-23 00:20 +0100
      Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-23 00:10 +0100
        Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-23 00:30 +0100
          Re: Amend Debian Python Proposal to Include More Python Metadata? Scott Kitterman <debian@kitterman.com> - 2016-01-23 01:20 +0100
            Re: Amend Debian Python Proposal to Include More Python Metadata? Donald Stufft <donald@stufft.io> - 2016-01-23 02:00 +0100
          pip as distutils/setuptools/setup.py wrapper Piotr Ożarowski <piotr@debian.org> - 2016-01-26 19:30 +0100

csiph-web