search

unrblt / beets-bandcamp

Plugin for beets (http://beets.io) to use bandcamp as an autotagger source.
GNU General Public License v2.0
63 stars 6 forks source link

__init__.py installation collides with beets #10

Closed BrainDamage closed 4 years ago

BrainDamage commented 4 years ago

the file beetsplug/__init__.py is already part of beets and setup.py attempts to overwrite it. when trying to make a distro package of this program it will make the package manager complain about the conflict since beets already ships that file, it shouldn't be necessary to install it

unrblt commented 4 years ago

Hi, thank you and sorry it took so long. Are you still trying to do this? All the beets plugins I see include the beetsplug/__init__.py and it doesn't seem to conflict with package managers. It seems to me that this should be handled as part of the packaging process (but have never done that, so I might be wrong). Feel free to reopen with more info if you need.

BrainDamage commented 4 years ago

Well, it currently is handled as part of the packaging process: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=beets-bandcamp and the same operation has to be other for other plugins too, e.g. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=beets-check https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=beets-alternatives This is not really a solution, it's just a workaround for cargo-culted setup.py that plugins share, the proper way would be to not install the file by the build system when installing it. The beets documentation refers to develop a plugin in a virtualenv or with a custom python path so that the plugin is isolated from the others, but that's not the case for a system-wide installation; this is good for development, but not deployment. The reason that you need an __init__.py script is that your plugin folder in the git repository is not part of the system-wide installation, but the moment you install it system-wide, then the __init__.py becomes redundant with every other plugin (and beets itself!) because everyone attempts to overwrite the same location. I'm not going to insist on the issue; I just wanted to report because arch packaging guidelines recommend doing the least amount of downstream changes and bugs should be handled upstream when possible.