This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients dsuch, lemburg, pitrou, tarek, techtonik
Date 2009-10-06.15:24:05
SpamBayes Score 3.952394e-14
Marked as misclassified No
Message-id <4ACB6113.9090605@egenix.com>
In-reply-to <d34314100910060807o583f94a9yf107fe308502daed@mail.gmail.com>
Content
anatoly techtonik wrote:
> 
> anatoly techtonik <techtonik@gmail.com> added the comment:
> 
> On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
> <report@bugs.python.org> wrote:
>>>
>>> Please, be specific. PyPi maintainer or trac-plugin package maintainer
>>> or debian package maintainer? Which should be mentioned in debian
>>> package for a trac plugin uploaded to PyPi for easy_install?
>>
>> The maintainer of the plugin.
>>
> 
> So, the maintainer of the plugin is mentioned in setup.py, but this
> field is also used in PyPi and the person who maintains it there wants
> some attribution. Should this person change maintainer field to
> himself?

We have a long description field for such things. If you look on PyPI
that field is even being used for complete documentation of a package,
so adding a note about some extra maintainer is certainly within
range.

>>> Is distutils format extensible? Can you create example of extending
>>> distutils format using this maintainer use case, so that every project
>>> can add their own maintainer fields if they need them? If it is
>>> impossible then I suggest to stop this discussion and start planning
>>> extensible distutils2 format with setup2.py and other2 files.
>>
>> The meta-data format is versioned, so it's well possible to
>> add new fields to it or make changes in core distutils.
> 
> No, that's not the way. Suppose we have three independent external
> frameworks that use setup.py files for deploying their
> plugins/components. All three need to extend distutils format. Which
> version should they choose? What if official distutils release will
> decide to use this version? Will other tools parse all these new
> versions correctly?

There's only one official distutils meta-format: that of core distutils.

Up until now, we've only added new fields, so old tools will
continue to work (but not know about the new fields).

>> It's even possible to extend if in custom setup scripts,
>> provided you know your way around in distutils. Have a
>> look at dist.py. You'll need to write a Distribution sub-class
>> and register this via the distclass setup() parameter.
> 
> As you may see I definitely do not know my way in distutils. =) Can
> you show the example of extending setup.py with pypi_maintainers
> field, that includes emails that should be granted maintainer rights
> by PyPi automatically on setup.py submission? It is not that I am
> challenging you to something - I just want to say that there are not
> many people who knows distutils like you to create the best solution
> for this user story. Even if it can be a tedious task the outcome is
> really important for further distutils usability improvement.

I don't have time for such challenges. Like I said: it's possible
and easy to do, but that doesn't necessarily mean that adding
custom fields to the meta-file format should be encouraged.

I also don't think that distutils meta data should be used
for automatic administration of tools such as PyPI. It has
purely informational character and helps in searching or
browsing Python packages. Nothing more.
History
Date User Action Args
2009-10-06 15:24:08lemburgsetrecipients: + lemburg, dsuch, pitrou, techtonik, tarek
2009-10-06 15:24:06lemburglinkissue6992 messages
2009-10-06 15:24:05lemburgcreate