Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
On Jan 13, 2017, at 10:08 AM, Lukasz Langa wrote: >PEP: 541 >Title: Package Index Name Retention Overall, +1 I agree with Steve that some short term name squatting may be appropriate. I'm not sure how you would word that in the PEP, but it will probably effectively work itself out anyway. When I come up with a name for a new project, one of the first things I do is check PyPI and reserve it before the first upload. But that first upload will usually happen pretty quickly. >Name conflict resolution for active projects > > >The maintainers of the Package Index are not arbiters in disputes >around *active* projects. There are many possible scenarios here, >a non-exclusive list describing some real-world examples is presented >below. None of the following qualify for package name ownership >transfer: This is another opportunity to encourage cooperation among the parties to resolve naming conflicts. I think that's what's called for by the CoC, and the hope is that the vast majority of disputes (in practice which I think are pretty rare anyway) can be amicably resolved. It does bring to mind the ability or lack thereof for renaming projects. IIRC that's not possible in current PyPI software but it may be possible in Warehouse. As for trademark owners having priority over names, I suppose there's no way to prevent that, I'm mostly glad that this PEP doesn't speak to that. I'm always edgy about the imbalance of power inherent in the issue, allowing a trademark owner to abuse their power to take over long-established names. OTOH, trademark owners do often have legitimate concerns against squatters. So, I say leave all that out of the PEP. Cheers, -Barry pgpQu7rVwaCrW.pgp Description: OpenPGP digital signature ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
This is a great PEP, glad to see an official policy being worked on! The "reachability" criteria I think should define how promptly the responses are expected and to what email(s) they will be sent (if there are multiple maintainers, owners, authors, etc.). For example, "the first contact will be sent to the email on record for all owners, maintainers, and the most-recent release author, in order to notify the user(s) that another party has requested classification of a PyPI project owned or maintained by the user as abandoned, and that if no response is received by (date of email + 6 weeks), it will be deemed abandoned. Reminder emails will be sent 2 and 4 weeks later." Maybe outside the scope of the PEP, but where will the tracker for these things reside? How would I, for example, start the process of flagging a project as abandoned? On Fri, Jan 13, 2017 at 1:13 PM, M.-A. Lemburg wrote: > On 13.01.2017 19:08, Lukasz Langa wrote: > > Invalid projects > > > > > > A project published on the Package Index meeting ANY of the following > > is considered invalid and will be removed from the Index: > > > > * project does not conform to Terms of Use; > > * project is malware (designed to exploit or harm systems or users); > > * project contains illegal content; > > * project violates copyright or licenses; > > This probably also needs to list "trademarks" and "patents", > as we've already had some cases where packages were violating > trademarks/patents and had to be removed (not only regarding the > name of the package but also regarding contents of the package or > functionality). This is already mentioned in the current terms, > but better make it more explicit here as well. > > Likewise, a trademark owner should be able to reserve project > names with the trademark to avoid any such issues to begin with, > e.g. https://pypi.python.org/pypi/Python is such a project :-) > > > * project is name squatting (package has no functionality or is > > empty); > > * project name, description, or content violates the Code of Conduct; > > or > > * project is abusing the Package Index for purposes it was not > > intended. > > > > If you find a project that might be considered invalid, create > > a support request [7]_. > > It would also be good to add some wording which makes it clear > that the PSF Board has the final say in any disputes and can > have a project removed/reassigned after careful consideration > even when not meeting all the requirements listed in the PEP. > > As an example, the last two bullets you mention above will > often be subject to additional judgement. The board would then have > to decide these on a case-by-case basis. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Jan 13 2017) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > > > ::: We implement business ideas - efficiently in both time and costs ::: > >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/ > http://www.malemburg.com/ > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
On 13.01.2017 19:08, Lukasz Langa wrote: > Invalid projects > > > A project published on the Package Index meeting ANY of the following > is considered invalid and will be removed from the Index: > > * project does not conform to Terms of Use; > * project is malware (designed to exploit or harm systems or users); > * project contains illegal content; > * project violates copyright or licenses; This probably also needs to list "trademarks" and "patents", as we've already had some cases where packages were violating trademarks/patents and had to be removed (not only regarding the name of the package but also regarding contents of the package or functionality). This is already mentioned in the current terms, but better make it more explicit here as well. Likewise, a trademark owner should be able to reserve project names with the trademark to avoid any such issues to begin with, e.g. https://pypi.python.org/pypi/Python is such a project :-) > * project is name squatting (package has no functionality or is > empty); > * project name, description, or content violates the Code of Conduct; > or > * project is abusing the Package Index for purposes it was not > intended. > > If you find a project that might be considered invalid, create > a support request [7]_. It would also be good to add some wording which makes it clear that the PSF Board has the final say in any disputes and can have a project removed/reassigned after careful consideration even when not meeting all the requirements listed in the PEP. As an example, the last two bullets you mention above will often be subject to additional judgement. The board would then have to decide these on a case-by-case basis. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 13 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: 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/ http://www.malemburg.com/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
On 13Jan2017 1050, Lukasz Langa wrote:
Thanks for review, Steve!
On Jan 13, 2017, at 10:35 AM, Steve Dower wrote:
An *abandoned* project can be transferred to a new owner for purposes
of reusing the name when ALL of the following are met:
...
The list here is nearly identical to the previous section
The "skin in the game" behavior is different.
Fair enough. Perhaps we should avoid using the idiom though (as
suggested earlier) to avoid any potential loss in translation.
I would actually like to be able to name-squat for a period between a project
being started and being released (particularly in my own context, I often need
to keep a project private until it has been internally tested/reviewed/scanned
and the lawyers have signed off, at which point it may require a new review if
the name has to change).
Presumably for a reachable uploader who can give an explanation, this won't result in the
immediate loss of the name. But suggesting a time limit may help reduce support requests
("project is name squatting for at least 6 months" feels okay to me, but not
wedded to it).
I don't want to suggest arbitrary limits on acceptable name squatting because
this can be abused. As long as you squat and nobody calls you out on it before
your first functional release, that's okay. If you squat on a great name and
somebody comes along with an existing notable project wanting that name, the
case it rather clear though.
So perhaps name-squatting belongs in the "this project is abandoned and
I want the name" section rather than the "this project is invalid and
I'm flagging it via support channels" section? (Or maybe I misunderstood
the intent of the separate sections, which I'm sure is also useful
feedback :) )
(As a semi-related aside, I'm currently squatting on the 'microsoft' and
'windows' packages for trademark protection reasons. They may never get any
functionality, but that's better than someone else having the name. This sort
of squatting doesn't necessarily need to be explicitly called out in policy,
but maybe it's worth a mention?)
I wanted to avoid touching on trademark issues because IANAL.
Very good point. Since nobody directly involved in this policy is a
lawyer, it might be worth clearly stating what the index maintainers are
responsible for in the case of a potential legal dispute with an
unreachable package owner, or one who is deliberately/maliciously making
themselves unreachable.
Or maybe it's a rare enough case that it doesn't matter? We certainly
resolved our last issue easily enough, though it did require the index
maintainers to put us in direct contact with the package owner. Maybe
stating that "the index maintainers are not responsible for evaluating
the legal status of intellectual property, and may only establish direct
contact between the complainant and a reachable package owner with
mutual consent" is the way to go? (And get VanL to sign off on the
wording, just in case there's some oddity here I'm not aware of.)
Cheers,
Steve
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
Thanks for review, Steve!
> On Jan 13, 2017, at 10:35 AM, Steve Dower wrote:
>
> I don't see any reason to expect the index maintainers to trawl through a
> project's documentation or home page to find contact details. There are more
> than enough ways to provide it on the index, and as far as I'm concerned, no
> reason for uploaders to not provide one.
The reason of this is courtesy towards existing package owners who might not
have conformed to the Author e-mail requirement because it wasn't explicitly
formulated. I think the maintainers would try their best to reach the owner
anyway, just to be sure there won't be any harm caused by changes.
>> An *abandoned* project can be transferred to a new owner for purposes
>> of reusing the name when ALL of the following are met:
>> ...
>
> The list here is nearly identical to the previous section
The "skin in the game" behavior is different.
> it's not clear on reading why we need to list these twice.
It's a different case and I want to limit back-and-forth required by the
readers (which is already necessary to parse the rules for abandoned projects).
> I would actually like to be able to name-squat for a period between a project
> being started and being released (particularly in my own context, I often
> need to keep a project private until it has been internally
> tested/reviewed/scanned and the lawyers have signed off, at which point it
> may require a new review if the name has to change).
>
> Presumably for a reachable uploader who can give an explanation, this won't
> result in the immediate loss of the name. But suggesting a time limit may
> help reduce support requests ("project is name squatting for at least 6
> months" feels okay to me, but not wedded to it).
I don't want to suggest arbitrary limits on acceptable name squatting because
this can be abused. As long as you squat and nobody calls you out on it before
your first functional release, that's okay. If you squat on a great name and
somebody comes along with an existing notable project wanting that name, the
case it rather clear though.
> (As a semi-related aside, I'm currently squatting on the 'microsoft' and
> 'windows' packages for trademark protection reasons. They may never get any
> functionality, but that's better than someone else having the name. This sort
> of squatting doesn't necessarily need to be explicitly called out in policy,
> but maybe it's worth a mention?)
I wanted to avoid touching on trademark issues because IANAL.
- Ł
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
Looks great to me. Just a few comments that may help reduce the burden
on the index maintainers.
On 13Jan2017 1008, Lukasz Langa wrote:
In every case where contacting the user is necessary,
the maintainers will try to do so at least three times, using the
following means of contact:
* the e-mail address on file in the user's profile on the Package Index;
* the e-mail address listed in the Author field for a given project
uploaded to the Index; and
* any e-mail addresses found in the given project's documentation
on the Index or on the listed Home Page.
The maintainers stop trying to reach the user after six weeks.
I don't see any reason to expect the index maintainers to trawl through
a project's documentation or home page to find contact details. There
are more than enough ways to provide it on the index, and as far as I'm
concerned, no reason for uploaders to not provide one.
An *abandoned* project can be transferred to a new owner for purposes
of reusing the name when ALL of the following are met:
...
The list here is nearly identical to the previous section, apart from
the added data point of download count (which is good!), and it's not
clear on reading why we need to list these twice.
Invalid projects
A project published on the Package Index meeting ANY of the following
is considered invalid and will be removed from the Index:
...
* project is name squatting (package has no functionality or is
empty);
...
If you find a project that might be considered invalid, create
a support request [7]_.
I would actually like to be able to name-squat for a period between a
project being started and being released (particularly in my own
context, I often need to keep a project private until it has been
internally tested/reviewed/scanned and the lawyers have signed off, at
which point it may require a new review if the name has to change).
Presumably for a reachable uploader who can give an explanation, this
won't result in the immediate loss of the name. But suggesting a time
limit may help reduce support requests ("project is name squatting for
at least 6 months" feels okay to me, but not wedded to it).
(As a semi-related aside, I'm currently squatting on the 'microsoft' and
'windows' packages for trademark protection reasons. They may never get
any functionality, but that's better than someone else having the name.
This sort of squatting doesn't necessarily need to be explicitly called
out in policy, but maybe it's worth a mention?)
Cheers,
Steve
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
On 01/13/2017 10:08 AM, Lukasz Langa wrote: I'd like to get some comments on this. I was asked by Donald to work on it. It removes ambiguity from some of the situations that crop up increasingly often with regards to package names on the PyPI. Looking forward to hearing what you have to say! Overall looks great. I would suggest removing slang, such as "skin in the game". Thanks for working on this! -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
+1 on the proposal. I would suggest to state where it is posted (somewhere obvious) on pypi, and possibly some kind of automated notification to pypi uploaders be provided about the new policy. On Fri, Jan 13, 2017 at 10:08 AM, Lukasz Langa wrote: > Hello distutils-sig, > I'd like to get some comments on this. I was asked by Donald to work on > it. It removes ambiguity from some of the situations that crop up > increasingly often with regards to package names on the PyPI. Looking > forward to hearing what you have to say! > - Ł > > > PEP: 541 > Title: Package Index Name Retention > Version: $Revision$ > Last-Modified: $Date$ > Author: Łukasz Langa > Status: Draft > Type: Process > Content-Type: text/x-rst > Created: 12-January-2017 > > > Abstract > > > This PEP proposes an extension to the Terms of Use [1]_ of the Package > Index [2]_, clarifying expectations of package owners regarding > ownership of a package name on the Package Index, specifically with > regards to conflict resolution. > > Existing package repositories such as CPAN [3]_, NPM [4]_, and > GitHub [5]_ will be investigated as prior art in this field. > > > Rationale > = > > Given that package names on the Index are sharing a single flat > namespace, a unique name is a finite resource. The growing age of > the Package Index causes a constant rise of situations of conflict > between the current use of the name and a different suggested use of > the same name. > > This document aims to provide general guidelines for solving the > most typical cases of such conflicts. > > > Specification > = > > The main idea behind this document is that the Package Index serves the > community. Every user is invited to upload content to the Package Index > under the Terms of Use, understanding that it is at the sole risk of > the user. > > While the Package Index is not a backup service, the maintainers of the > Package Index do their best to keep that content accessible indefinitely > in its published form. However, in certain edge cases the greater > community's needs might overweigh the individual's expectation of > ownership of a package name. > > The use cases covered by this document are: > > * Abandoned projects: > > * continued maintenance by a different set of users; or > * removal from the Index for use with a different project. > > * Active projects: > > * resolving disputes over a name. > > * Invalid projects. > > > Implementation > == > > Reachability > > > The user of the Package Index is solely responsible for being reachable > by the Package Index maintainers for matters concerning projects that > the user owns. In every case where contacting the user is necessary, > the maintainers will try to do so at least three times, using the > following means of contact: > > * the e-mail address on file in the user's profile on the Package Index; > * the e-mail address listed in the Author field for a given project > uploaded to the Index; and > * any e-mail addresses found in the given project's documentation > on the Index or on the listed Home Page. > > The maintainers stop trying to reach the user after six weeks. > > > Abandoned projects > -- > > A project is considered *abandoned* when ALL of the following are met: > > * owner not reachable (see Reachability above); > * no releases within the past twelve months; and > * no activity from the owner on the project's home page (or no > home page listed). > > All other projects are considered *active*. > > > Continued maintenance of an abandoned project > - > > If a candidate appears willing to continue maintenance on an *abandoned* > project, ownership of the name is transferred when ALL of the following > are met: > > * the project has been determined *abandoned* by the rules described > above; > * the candidate is able to demonstrate own failed attempts to contact > the existing owner; > * the candidate is able to demonstrate skin in the game (improvements > made on the candidate's own fork of the project); > * the candidate is able to demonstrate why a fork under a different name > is not an acceptable workaround; and > * the maintainers of the Package Index don't have any additional > reservations. > > Under no circumstances will a name be reassigned against the wishes of > a reachable owner. > > > Removal of an abandoned project > --- > > Projects are never removed from the Package Index solely on the basis > of abandonment. Artifacts uploaded to the Package Index hold inherent > historical value. > > An *abandoned* project can be transferred to a new owner for purposes > of reusing the name when ALL of the following are met: > > * the project has been determined *abandoned* by the rules described > above; > * the candidate is able to demonstrate own failed attempts to contact > the existing owner; > * the candidate i
[Distutils] RFC: PEP 541 - Package Index Name Retention
Hello distutils-sig, I'd like to get some comments on this. I was asked by Donald to work on it. It removes ambiguity from some of the situations that crop up increasingly often with regards to package names on the PyPI. Looking forward to hearing what you have to say! - Ł PEP: 541 Title: Package Index Name Retention Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa Status: Draft Type: Process Content-Type: text/x-rst Created: 12-January-2017 Abstract This PEP proposes an extension to the Terms of Use [1]_ of the Package Index [2]_, clarifying expectations of package owners regarding ownership of a package name on the Package Index, specifically with regards to conflict resolution. Existing package repositories such as CPAN [3]_, NPM [4]_, and GitHub [5]_ will be investigated as prior art in this field. Rationale = Given that package names on the Index are sharing a single flat namespace, a unique name is a finite resource. The growing age of the Package Index causes a constant rise of situations of conflict between the current use of the name and a different suggested use of the same name. This document aims to provide general guidelines for solving the most typical cases of such conflicts. Specification = The main idea behind this document is that the Package Index serves the community. Every user is invited to upload content to the Package Index under the Terms of Use, understanding that it is at the sole risk of the user. While the Package Index is not a backup service, the maintainers of the Package Index do their best to keep that content accessible indefinitely in its published form. However, in certain edge cases the greater community's needs might overweigh the individual's expectation of ownership of a package name. The use cases covered by this document are: * Abandoned projects: * continued maintenance by a different set of users; or * removal from the Index for use with a different project. * Active projects: * resolving disputes over a name. * Invalid projects. Implementation == Reachability The user of the Package Index is solely responsible for being reachable by the Package Index maintainers for matters concerning projects that the user owns. In every case where contacting the user is necessary, the maintainers will try to do so at least three times, using the following means of contact: * the e-mail address on file in the user's profile on the Package Index; * the e-mail address listed in the Author field for a given project uploaded to the Index; and * any e-mail addresses found in the given project's documentation on the Index or on the listed Home Page. The maintainers stop trying to reach the user after six weeks. Abandoned projects -- A project is considered *abandoned* when ALL of the following are met: * owner not reachable (see Reachability above); * no releases within the past twelve months; and * no activity from the owner on the project's home page (or no home page listed). All other projects are considered *active*. Continued maintenance of an abandoned project - If a candidate appears willing to continue maintenance on an *abandoned* project, ownership of the name is transferred when ALL of the following are met: * the project has been determined *abandoned* by the rules described above; * the candidate is able to demonstrate own failed attempts to contact the existing owner; * the candidate is able to demonstrate skin in the game (improvements made on the candidate's own fork of the project); * the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround; and * the maintainers of the Package Index don't have any additional reservations. Under no circumstances will a name be reassigned against the wishes of a reachable owner. Removal of an abandoned project --- Projects are never removed from the Package Index solely on the basis of abandonment. Artifacts uploaded to the Package Index hold inherent historical value. An *abandoned* project can be transferred to a new owner for purposes of reusing the name when ALL of the following are met: * the project has been determined *abandoned* by the rules described above; * the candidate is able to demonstrate own failed attempts to contact the existing owner; * the candidate is able to demonstrate skin in the game (the other project suggested to reuse the name already exists and meets notability requirements); * the candidate is able to demonstrate why a fork under a different name is not an acceptable workaround; * download statistics on the Package Index for the existing package indicate project is not being used; and * the maintainers of the Package Index don't have any additional reservations. Name conflict resolution for active projects ---
Re: [Distutils] How to specify dependencies in Python
On Fri, Jan 13, 2017 at 7:23 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > What is an application for you? Another way to think about this, FWIW, is to distinguish between the "whole system" (for which "Application" is often a useful shorthand), as opposed to components (aka libraries). It's important for components to be flexible, so they're typically very flexible about versions of their dependencies. For whole systems, OTOH, it's important that once a configuration is tested, that the same configuration is used in production, so systems typically pin all of their dependencies, ideally extending to their environments (which is a reason why container technology is attractive). Jim -- Jim Fulton http://jimfulton.info ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] How to specify dependencies in Python
It's probably a good idea here to explicitly distinguish between the kind
of application that's a web app you deploy to sort of managed server
environment, and the kind of application that's a command line or GUI tool
that people download and run. The same word means radically different
things to different people :-). I believe Paul's advice below is
specifically addressing the former case, not the latter.
On Jan 13, 2017 5:07 AM, "Paul Moore" wrote:
> On 13 January 2017 at 12:23, Thomas Güttler
> wrote:
> > Am 12.01.2017 um 13:43 schrieb Nick Coghlan:
> >>
> >> On 12 January 2017 at 22:04, Thomas Güttler
> >> wrote:
> >>>
> >>> I came across a python library which has docs, which start like this:
> >>>
> >>> {{{
> >>>
> >>> Quickstart
> >>>
> >>> Include foolib in your requirements.txt file.
> >>>
> >>> }}}
> >>>
> >>> AFAIK dependencies should be specified via `install_requires` in
> >>> `setup.py`.
> >>
> >>
> >> Applications and services don't necessarily have a setup.py file -
> >> setup.py is more for pip-installable libraries and frameworks (see
> >> https://caremad.io/posts/2013/07/setup-vs-requirement/ for more on
> >> that topic).
> >
> >
> > What is an application?
> >
> > The django project uses this definition:
> > https://docs.djangoproject.com/en/1.10/ref/applications/
> >
> > I guess you mean something else, if you talk about "application".
> >
> > What is an application for you?
>
> IMO, an "application" in this context is a standalone program
> (implemented in Python). This is as opposed to a "library" which is
> written to be imported in other Python code. Obviously, there's some
> overlap - some "applications" provide a "programming API" that can be
> imported, and some libraries provide command line entry points.
>
> A library (something that you import) should declare in its metadata
> that you need to have its dependencies installed before it will work.
> That lets you (the user of the library) be ignorant of the
> dependencies of the library (which are implementation details as far
> as you are concerned) - pip just sorts it out for you from the
> metadata. To get the dependency metadata, the *library* should include
> its dependencies in install_requires in its setup.py.
>
> For applications on the other hand, you need to install exactly the
> environment you tested, so you *don't* use dependency metadata.
> Rather, you create a requirements.txt file that contains the exact
> versions of everything (direct dependencies) your application needs,
> then deploy your application script to a Python environment where
> you've run "pip install -r requirements.txt" to set it up correctly.
>
> As I say, there are lots of grey areas here. But from your
> description, the library you found sounds like it should have
> dependency metadata, and not need you to use a requirements file. On
> the other hand, the "Quickstart" may be trying to tell people how to
> use foolib in their *application*, in which case it's correct. (It's
> oversimplified, as if you're writing a library that depends on foolib
> you'd use install_requires, but simply changing the text to just say
> "put foolib in your install_requires" is no better, as then you'd have
> ignored the application use case...)
>
> If you can point to the actual library you're referring to, it would
> be easier to be specific :-)
>
> Paul
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] How to specify dependencies in Python
On 13 January 2017 at 12:23, Thomas Güttler
wrote:
> Am 12.01.2017 um 13:43 schrieb Nick Coghlan:
>>
>> On 12 January 2017 at 22:04, Thomas Güttler
>> wrote:
>>>
>>> I came across a python library which has docs, which start like this:
>>>
>>> {{{
>>>
>>> Quickstart
>>>
>>> Include foolib in your requirements.txt file.
>>>
>>> }}}
>>>
>>> AFAIK dependencies should be specified via `install_requires` in
>>> `setup.py`.
>>
>>
>> Applications and services don't necessarily have a setup.py file -
>> setup.py is more for pip-installable libraries and frameworks (see
>> https://caremad.io/posts/2013/07/setup-vs-requirement/ for more on
>> that topic).
>
>
> What is an application?
>
> The django project uses this definition:
> https://docs.djangoproject.com/en/1.10/ref/applications/
>
> I guess you mean something else, if you talk about "application".
>
> What is an application for you?
IMO, an "application" in this context is a standalone program
(implemented in Python). This is as opposed to a "library" which is
written to be imported in other Python code. Obviously, there's some
overlap - some "applications" provide a "programming API" that can be
imported, and some libraries provide command line entry points.
A library (something that you import) should declare in its metadata
that you need to have its dependencies installed before it will work.
That lets you (the user of the library) be ignorant of the
dependencies of the library (which are implementation details as far
as you are concerned) - pip just sorts it out for you from the
metadata. To get the dependency metadata, the *library* should include
its dependencies in install_requires in its setup.py.
For applications on the other hand, you need to install exactly the
environment you tested, so you *don't* use dependency metadata.
Rather, you create a requirements.txt file that contains the exact
versions of everything (direct dependencies) your application needs,
then deploy your application script to a Python environment where
you've run "pip install -r requirements.txt" to set it up correctly.
As I say, there are lots of grey areas here. But from your
description, the library you found sounds like it should have
dependency metadata, and not need you to use a requirements file. On
the other hand, the "Quickstart" may be trying to tell people how to
use foolib in their *application*, in which case it's correct. (It's
oversimplified, as if you're writing a library that depends on foolib
you'd use install_requires, but simply changing the text to just say
"put foolib in your install_requires" is no better, as then you'd have
ignored the application use case...)
If you can point to the actual library you're referring to, it would
be easier to be specific :-)
Paul
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] How to specify dependencies in Python
Am 12.01.2017 um 13:43 schrieb Nick Coghlan:
On 12 January 2017 at 22:04, Thomas Güttler
wrote:
I came across a python library which has docs, which start like this:
{{{
Quickstart
Include foolib in your requirements.txt file.
}}}
AFAIK dependencies should be specified via `install_requires` in `setup.py`.
Applications and services don't necessarily have a setup.py file -
setup.py is more for pip-installable libraries and frameworks (see
https://caremad.io/posts/2013/07/setup-vs-requirement/ for more on
that topic).
What is an application?
The django project uses this definition:
https://docs.djangoproject.com/en/1.10/ref/applications/
I guess you mean something else, if you talk about "application".
What is an application for you?
Regards,
Thomas Güttler
--
Thomas Guettler http://www.thomas-guettler.de/
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
