[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Tarek Ziadé]

Tarek Ziadé  added the comment:

This discussion is taken to distutils-SIG, and a PEP 345 update is being
worked out there. (look for 'RFC PEP 345' in Distutils archives)

I am closing this issue and proposes that we continue there.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

anatoly techtonik wrote:
> 
> anatoly techtonik  added the comment:
> 
> On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
>  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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[anatoly techtonik]

anatoly techtonik  added the comment:

On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg
 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?

>> 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?

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

anatoly techtonik wrote:
> 
> anatoly techtonik  added the comment:
> 
>>> Tarek Ziadé  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?

The maintainer of the plugin.

>> 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.

The meta-data format is versioned, so it's well possible to
add new fields to it or make changes in core distutils.

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[anatoly techtonik]

anatoly techtonik  added the comment:

>> Tarek Ziadé  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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Tarek Ziadé wrote:
> 
> Tarek Ziadé  added the comment:
> 
>> I'm just suggesting to add the meta-data field in order to recreate
>> consistency - not advocating that setup() parameter or its use.
> 
> 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
> 
> While I understand your PoV about the fact that B/ is not impacting
> existing packages and doesn't require any deprecation, I would like to
> find some use cases for having such fields in the Metadata, other than
> fixing the inconsistency.
> 
> 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.

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[anatoly techtonik]

anatoly techtonik  added the comment:

I wonder what does Guido think about this bikeshed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Dariusz Suchojad]

Dariusz Suchojad  added the comment:

Hello,

funny the bug report should surface in the very same time I was looking
for a way to put 2 authors in the 'author' field :-)

[Antoine Pitrou (pitrou)]
> It is still unknown what use case the new "author" scheme would solve 
> that the old one doesn't

I believe I have such a use case. I'm in the middle of taking over a
Python package and I would like to give credits to the original author
who passed the development over to me. You see, *he is* the author of
95% of the code, it seems unfair to replace his name with my own. I
thought I could simply use a list of authors but the 'author' field
hasn't been designed for it.

[Antoine Pitrou (pitrou)]
> (does someone want the "author"field to be machine parsable?
> for what purpose?),

I'm just a regular user and when I see a field described as a 'meta' one
then I'm actually not wondering how any future tools will take 
advantage of it. It being a 'meta' I understand it's mostly meant to be
interpreted by machines which, funnily enough, seems to be just to the
contrary of what you say.

Of course one can put anything they wish into 'author', it could even 
be CSV or XML but that's not the point, the point is that some things
simply have two and more authors and inserting the mailing list isn't
exactly the same. Sure, I can simply put it all in an AUTHORS file but
again it's not the same, what would be the 'author' field for then?

If someone were to ask me then I'd say there should only be the 'author'
and 'contributor' fields which both have a clear meaning in open-source
world, accepting both a string and a list/tuple in format of 'Foo Bar
' which makes for easy parsing and other fields
discussed here should be deprecated. No one likes type checking but at
least it would provide backwards-compat for the most widely used field.
Just my 2c.

author = 'Foo Bar '
author = ['Foo Bar ', 'Baz Frobble
']

But hey, I still very much like distutils :-) and I understand all the 
backwards-compatibility concerns, but as a user I can clearly see a need
for /some/ way to specify more than one author without having to wonder
what will any not-yet-written tool do with this or any other meta field.

--
nosy: +dsuch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

[Tarek Ziadé]

Tarek Ziadé  added the comment:

> I'm just suggesting to add the meta-data field in order to recreate
> consistency - not advocating that setup() parameter or its use.

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

While I understand your PoV about the fact that B/ is not impacting
existing packages and doesn't require any deprecation, I would like to
find some use cases for having such fields in the Metadata, other than
fixing the inconsistency.

If we don't have a use case, I'd go for A/

--
title: Adding a Contributor field in PEP 314 -> PEP 314 inconsistency 
(authors/author/maintainer)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com