Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Sun, Dec 09, 2012 at 01:51:09PM +1100, Chris Angelico wrote: On Sun, Dec 9, 2012 at 1:11 PM, Steven D'Aprano st...@pearwood.info wrote: Why would a software package called Spam install a top-level module called Jam rather than Spam? Isn't the whole point of Python packages to solve this namespace problem? That would require/demand that the software package MUST define a module with its own name, and MUST NOT define any other top-level modules, and also that package names MUST be unique. (RFC 2119 keywords.) That would work, as long as those restrictions are acceptable. /me notes that setuptools itself is an example of a package that violates this rule )setuptools and pkg_resources). No objections to That would work, as long as those restrictions are acceptable that seems to sum up where we're at. -Toshio pgpC3zr5ZrDtv.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Sun, Dec 09, 2012 at 12:48:45AM -0500, PJ Eby wrote: Do any of the distro folks know of a Python project tagged as conflicting with another for their distro, where the conflict does *not* involve any files in conflict? In Fedora we do work to avoid most types of Conflicts (backporting fixes, etc) but I can give some examples of where Conflivts could have been used in the past: In docutils prior to the latest release, certain portions of docutils was broken if pyxml was installed (since pyxml replaces certain stdlib xml.* functionaltiy). So older docutils versions could have had a Conflicts: PyXML. Nick has since provided a technique for docutils to use that loads from the stdlib first and only goes to PyXML if the functionality is not available there. Various libraries in web stacks have had bugs that prevent the propser functioning of the web framework at the top level. In case of major issues (security, unable to startup), these top level frameworks could use versioned Conflicts to prevent installation. For instance: TurboGears might have a Conflicts: CherryPy 2.3.1 Note, though, that if parallel installable versions and selection of the proper versions from that work, then this type of Conflict wouldn't be necessary. Instead you'd have versioned Requires: instead. -Toshio pgpb06wUdfxFB.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Sun, Dec 9, 2012 at 12:15 PM, Steven D'Aprano st...@pearwood.info wrote: Assuming that two software packages Spam and Ham install into directories Spam and Ham, how can merely having them installed side-by-side lead to a conflict? I can see how running or importing Spam and Ham together might lead to problems. And I can see that if package Spam wants to install into directory Ham, that would be bad. But who does that? If two packages Spam and Ham both define a module Jam, then the one that gets loaded will depend on the search path. That would be one form of conflict. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On 09/12/12 12:32, Chris Angelico wrote: On Sun, Dec 9, 2012 at 12:15 PM, Steven D'Apranost...@pearwood.info wrote: Assuming that two software packages Spam and Ham install into directories Spam and Ham, how can merely having them installed side-by-side lead to a conflict? I can see how running or importing Spam and Ham together might lead to problems. And I can see that if package Spam wants to install into directory Ham, that would be bad. But who does that? If two packages Spam and Ham both define a module Jam, then the one that gets loaded will depend on the search path. That would be one form of conflict. import Spam.Jam import Ham.Jam What am I missing? Why would a software package called Spam install a top-level module called Jam rather than Spam? Isn't the whole point of Python packages to solve this namespace problem? -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Saturday, December 8, 2012 at 9:11 PM, Steven D'Aprano wrote: Why would a software package called Spam install a top-level module called Jam rather than Spam? Isn't the whole point of Python packages to solve this namespace problem? Conflicts doesn't really solve file based conflicts as PJ Elby has pointed out tools need to detect that circumstance already. But to answer this question no, there is no required mapping between Project names (what your thing is called on PyPI) and python package names (what you import). Something named Spam on PyPI could provide multiple python packages, named whatever it was they wanted to be named. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Sun, Dec 9, 2012 at 1:11 PM, Steven D'Aprano st...@pearwood.info wrote: On 09/12/12 12:32, Chris Angelico wrote: On Sun, Dec 9, 2012 at 12:15 PM, Steven D'Apranost...@pearwood.info wrote: Assuming that two software packages Spam and Ham install into directories Spam and Ham, how can merely having them installed side-by-side lead to a conflict? I can see how running or importing Spam and Ham together might lead to problems. And I can see that if package Spam wants to install into directory Ham, that would be bad. But who does that? If two packages Spam and Ham both define a module Jam, then the one that gets loaded will depend on the search path. That would be one form of conflict. import Spam.Jam import Ham.Jam What am I missing? Why would a software package called Spam install a top-level module called Jam rather than Spam? Isn't the whole point of Python packages to solve this namespace problem? That would require/demand that the software package MUST define a module with its own name, and MUST NOT define any other top-level modules, and also that package names MUST be unique. (RFC 2119 keywords.) That would work, as long as those restrictions are acceptable. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On 2012-12-09 01:15, Steven D'Aprano wrote: On 09/12/12 08:14, MRAB wrote: If package A says that it conflicts with package B, it may or may not be symmetrical, because it's possible that package B has been updated since the author of package A discovered the conflict, so it's important that the user is told which package is complaining about the conflict, the one that is being installed or the one that is already installed. I must admit than in reading this thread, I'm having a bit of trouble understanding why merely *installing* packages should lead to conflicts. [snip] Personally speaking, I was thinking more about possible problems at runtime due to functional conflicts, but it could apply to any (undefined) conflict. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Sat, Dec 8, 2012 at 10:22 PM, MRAB pyt...@mrabarnett.plus.com wrote: On 2012-12-09 01:15, Steven D'Aprano wrote: On 09/12/12 08:14, MRAB wrote: If package A says that it conflicts with package B, it may or may not be symmetrical, because it's possible that package B has been updated since the author of package A discovered the conflict, so it's important that the user is told which package is complaining about the conflict, the one that is being installed or the one that is already installed. I must admit than in reading this thread, I'm having a bit of trouble understanding why merely *installing* packages should lead to conflicts. [snip] Personally speaking, I was thinking more about possible problems at runtime due to functional conflicts, but it could apply to any (undefined) conflict. If it's for a runtime functional conflict, there's no need for installation tools to worry about it, except perhaps in the case where a single project C depends on *both* A and B, where A and B conflict with each other. Apart from that piece of information, there is no way to know that the code will ever even be imported at the same time. (And even then, it's just a hint of the possibility, not a guarantee.) Nick, OTOH, says that the purpose of the field is to declare that mere side-by-side installation invalidates developer support for the configuration. However, the widespread confusion (conflicts?) over what exactly the field is supposed to mean and when it should be used suggests that its charter is not nearly as clear as it should be. It seems perhaps it is suffering from the so-called Illusion of Transparency, wherein everybody looks at it and thinks that it *obviously* means X, and only a fool could think otherwise... except that everyone has a *different* value of X in mind. That's why I keep asking for specific, concrete use cases. At this point, for the field to make any sense, there needs to be some better idea of what a runtime or undefined conflict is. Apart from file conflicts, has anybody identified a single PyPI package that would make use of this field? If so, what *is* that example, and what is the nature of the conflict? Do any of the distro folks know of a Python project tagged as conflicting with another for their distro, where the conflict does *not* involve any files in conflict? (And the conflict is not specific to the distro's packaging of that project and the project in conflict? i.e., that it would have actually been possible and/or meaningful for the upstream developer to have flagged the conflict in the project's metadata, given the proposed metadata standard?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conflicts [was Re: Keyword meanings [was: Accept just PEP-0426]]
On Sun, Dec 9, 2012 at 3:48 PM, PJ Eby p...@telecommunity.com wrote: That's why I keep asking for specific, concrete use cases. At this point, for the field to make any sense, there needs to be some better idea of what a runtime or undefined conflict is. Apart from file conflicts, has anybody identified a single PyPI package that would make use of this field? If so, what *is* that example, and what is the nature of the conflict? The best current example I know of is whether or not a given package is gevent compatible. At the moment, you have to try it and see, or hope the project developers have a note somewhere saying whether or not it works. Incompatible might be a better field name than Conflicts for that use case, though. You've persuaded me that any installer based notification of runtime conflicts should at most be a warning (or even a separate query), since the user has so many options for dealing with it (including the typical case where the two components are simply never used in the same process). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
