1. Freso Fenderson Avatar Freso Fenderson
  2. Untitled project
  3. PKGBUILDs
  4. Issues

isrcsubmit-git: Dealing with Python 3 vs. Python 2

Issue #5 resolved
Freso Fenderson repo owner created an issue

So issue #4 has been resolved and the package is now a split one. However, this scenario isn't my ideal one, as it prevents users from doing $aurhelper -S isrcsubmit-git and installing the package without further intervention.

This can be "solved" in a few ways:

  1. As-is. This leaves people to choose manually which of the two they want to install.
  2. Drop Python 2 support in the package. Just install the Python 3 version. Python 2 zealots can easily make the package suit their taste by s/python/python2/'ing.
  3. Happy co-existence. Since the two versions install the library files to /usr/lib/python2.x/... and /usr/lib/python3.x/... respectively, simply renaming Python 2's /usr/bin/isrcsubmit.py to isrcsubmit-python2.py or something should allow the two versions to live happily alongside each other.

I'm leaning towards 2) myself, but if anyone has any opinion on the matter, feel free to contact me and share it.

Comments (6)

  2. Johannes Dewender

    There are no library files. The only thing that is installed in site-packages is the egg, which is the package information. Possibly that is needed when setup.py is used to handel dependencies or similar. I don't think we actually need this file, but it is standard. Anyways, all code resides in the isrcsubmit.py script.

    I couldn't find a standard way to provide and name python applications/programs for two different python versions. Not sure if there are many scripts/programs out there that work with both version. The reason is, that there isn't much advantage to providing both versions.

    For libraries the reason to provide two versions is so Python 3 and Python 2 tools can use the library. For scripts/programs there is no such need so we should just stick with the default python which is Python 3 on Arch Linux. I'd say. This is also what I did with the isrcsubmit release package.

    There is one advantage of choosing the Python 2 version and that is to save on installed packages when python2-discid and python2-musicbrainzngs are both needed. In this case not very relevant (two small libraries without additional (python2) dependencies). This is different when you pull in like 20 connected dependencies (I had that recently).

  3. Johannes Dewender

    There is a ticket to allow using isrcsubmit also as a module/library: https://github.com/JonnyJD/musicbrainz-isrcsubmit/pull/66 I am not yet sure how much sense that makes and if anybody would use it. I did have a request, but that was more like a morituri deficiency that can also be solved in other ways. (see ticket) Starting with implemented raw isrcs (possibly CD-TEXT isrcs) there is no actual need for isrcsubmit as a library. The only good reason would be an isrcsubmit GUI, but that would need more restructuring. Still I keep this ticket open and it kind of blocks the version 2 stable until it is decided.

    In that case the installation routine would change to installing isrcsubmit.py in site-packages and only link to it in /usr/bin. Even then having a split package might not be the way to go, since one package can't be found on AUR with tools. Last time I checked, there is no real split package support on the AUR (only in makepkg).

  4. Johannes Dewender

    If I didn't mention that earlier:

    The reason I didn't split isrcsubmit in a library file and one or more script files is solely because I want the script to run as 1 file without any installation or script location necessary.

    Otherwise I would love to split that up more.

  6. Freso Fenderson reporter

    I decided to go with solution 2, since your comments seemed to support my inkling. Cheers. :)

  7. Log in to comment
Assignee
–
Type
proposal
Priority
major
Status
resolved
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!