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 techtonik
Recipients dsuch, lemburg, pitrou, tarek, techtonik
Date 2009-10-06.12:53:10
SpamBayes Score 0.00012054127
Marked as misclassified No
Message-id <d34314100910060552u7096cb8ap3a69b7501a854fd8@mail.gmail.com>
In-reply-to <4AC8F559.5070201@egenix.com>
Content
>> Tarek Ziadé <ziade.tarek@gmail.com> added the comment:

>> Yes but fixing this inconsitency can be done on either side:
>> A - remove the maintainer and maintainer_email
>> B - add the Maintainer and Maintainer-email in the metadata

>> If we don't have a use case, I'd go for A/
>
> Having a maintainer for a package is not at all uncommon.
>
> Whether you put that maintainer into a separate field or not
> is really a mix of respect/taste/culture.

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?

> I'd go for B, since we already have the maintainer setup()
> variable and just need to add the missing meta-data field.
>
> Whether this gets used or not is up to 3rd party code
> using the meta-data to decide and not really a distutils
> question.

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.
History
Date User Action Args
2009-10-06 12:53:12techtoniksetrecipients: + techtonik, lemburg, dsuch, pitrou, tarek
2009-10-06 12:53:10techtoniklinkissue6992 messages
2009-10-06 12:53:10techtonikcreate