Repository navigation
Installed package conflict #7
Description
Hi, this package is installed as pydispatch, which conflicts with an older package https://pypi.org/project/pydispatch/ , hosted at http://pydispatcher.sourceforge.net/ , which happens to be packaged by most distros because it is a dependency of https://pypi.org/project/Scrapy/ .
See https://repology.org/project/pydispatcher/versions and https://repology.org/project/python:pydispatcher/versions
I am looking to create an openSUSE package for this project, and I can proceed by adding a Conflicts: marker in the .spec . But if there is any chance you might be considering renaming the installed package directory to avoid conflicts, that would avoid this conflict.
Activity
jayvdb commentedon Oct 29, 2019
Note if you did want to rename, you could include a shim at the old name, and distro packagers would simply omit that shim.
nocarryr commentedon Oct 29, 2019
Hi @jayvdb, thanks for bringing this up.
While I've never imagined this project would be used anywhere except for my own projects, a top-level namespace conflict is definitely an issue that I should correct. (Especially taking PEP-423 into account)
I'm not opposed to renaming. Even with the amount of refactoring involved and coming up with a shim/monkeypatch mechanism for backwards compatibility.
The biggest challenge - at least for me - is that naming things is hard. Especially with so many similar projects out there:
I'm totally open to suggestions and will be trying to come up with a solution, but I can't say how long it might be. Are you working on packaging for openSUSE as part of a larger project? Is there a timeline that you're trying to meet for it?
jayvdb commentedon Oct 29, 2019
No particular timeline, and unfortunately past midnight so low on naming-stuff-juice. I am looking for good options for lightweight observable containers, and this package is one of the better ones I have found, but I havent tried all of those you link too. You may want to distinguish this package on the fact it has reasonably easy to use observable containers (simpler/lighter than RxPY based https://pypi.org/project/observable-collections/). However the emitter holds the observable containers, so it isn't as direct as e.g.
undoable.nocarryr commentedon Oct 29, 2019
Ah, I can see how the containers in the
pydispatch.propertiesmodule would be useful on their own. It would be better to decouple them away from the descriptor mechanism (Property objects).I'll think on that too, thanks!
jayvdb commentedon Oct 29, 2019
https://pypi.org/project/observatory/#history was fairly recently taken ;-(
Another naming idea: observation is similar to mocking in how it can be used in testing.