[Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
M.-A. Lemburg
mal at egenix.com
Thu Oct 8 16:55:16 CEST 2009
Tarek Ziadé wrote:
> On Thu, Oct 8, 2009 at 1:27 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>>>> == The fate of setup.py, and static metadata ==
>>>>
>>>> So we are going to separate the metadata description from setup.py, in
>>>> a static configuration file, that can be open and read by anyone
>>>> without
>>>> running any code. The only problem with this is the fact that some
>>>> metadata fields might depend on the execution environment. For
>>>> instance, once "Requires" is re-defined and re-introduced via PEP 314,
>>>> we will have cases where "pywin32" will be a dependency to have only
>>>> on win32 systems.
>>
>> How are you planning to deal with dynamic version strings, e.g.
>> say you want to build a snapshot release the current date and
>> revision number included in the version string ?
>>
>> I suppose this file is going to be uploaded to PyPI, so the
>> file would have to be formatted at build time and include
>> markers to be replaced with values taken from the distribution
>> meta-data.
>
> The metadata will always be customizable from setup.py somehow.
>
> We won't treat those cases : if the metadata is provided in the static file,
> you can get it without any further processing, if not you will get an
> "UNKOWN" value
> for it and you will have to grab the whole archive and run setup.py to get it.
>
> Now the example you've shown is in my opinion not a problem : you can
> create the static value for "version" that you put in your static file
> with some pre-processing that
> occurs when you build your release. (ala autoconf)
Hmm, then I'm not really sure I understand the proposal for a
new static meta-data file...
distutils already creates the static meta-data file PKG-INFO
when building sdist distributions and that's done based on the
data read from the setup() call. It would be easy to use that
file as static meta-data file in other distribution formats
as well (e.g. like you proposed in PEP 376).
OTOH, the register command sends the meta-data directly to
the PyPI database, so it doesn't even need another file
for storing away the meta data.
Unless I'm missing something important (which I probably am),
the only added value of the new format over PKG-INFO is the
micro-language.
Couldn't we just stick that into the values of the various
meta-data fields, e.g. to have the Requires field be different
depending on platform ?
We'd then only have one meta-data format in distutils -
the PKG-INFO one.
>>>> - Work left to do : publish the final syntax, and do the implementation
>>
>> Is there a PEP for this ?
>
> No, but if you ask for it I can write it.
Please do. The format will need documentation anyway and the
motivation should be made clear as well.
>>>> == The fate of bdist_* commands ==
>>>>
>>>> So the best way to handle this is to ask these communities to build
>>>> their own tool and to encourage them to use Distutils as a basis for
>>>> that.
>>
>> Rather than having external communities build their own
>> tools and then basically fork distutils in order to get
>> these implemented, I think it'd be better to make the
>> set of distutils commands extensible via namespace packages.
>
> I am not sure, why they would fork distutils.
Not really a fork, but a copy of distutils in order to give
the user the complete tool set in one download, rather than
having to configure a system installed distutils to load
the new command.
> Distutils is already extensible, you can configure in distutils.cfg a
> list of namespace packages,
> that contains commands and they'll get loaded by dist.py.
Right, but dist.py could load all distutils.command modules
it can find to make the installation of extensions more user
friendly (like in a plugin system).
Just a minor nit, though.
>>>> So what is going to happen is a status-quo: no bdist_* command will be
>>>> removed but no new bdist_* command will be added.
>>
>> I hope that comment means "no new bdist_* command will be added
>> *right now*". It's well possible to create new bdist_* commands
>> that don't rely on external tool chains or only on ones that
>> don't change often.
>>
>> I'm thinking of bdist_inno (Windows installer using InnoSetup)
>> and bdist_nsis (Windows installer using NSIS) here.
>
> As I said, windows don't have any packaging system so I don't think
> it's a problem to have more installers for this platform.
Ok.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 08 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
More information about the Python-Dev
mailing list