LordSputnik
Port changes to original mutagen project
Get mutagen itself working on Python 3.3 and Python 2.6. Then close this project, since it's achieved its goals of creating a Python 3 compatible mutagen.
Can I please ask a quick question...?
From the recent commits you mention various python2 vs python3 fixes - but I'm a little confused with the project title and the README title as well as various statements saying this is a python3 only project.
The project title says "mutagen" - the README says "mutagenx". When I create a debian package for the latest stuff - should I be referring to the package-name mutagen or mutagenx? i.e. "python-mutagen" or "python3-mutagen" or maybe "python3-mutagenx".
Secondary - if mutagen - is the intention to support both python2 apps such as easytag as well as python3 apps? If yes to support both, then the debian package should overwrite and take precedence over the standard python2 "python-mutagen" package found in many distros. If its a python3 only install then maybe "python3-mutagen" or possibly "python3-mutagenx"
To clarify:
Originally, there wasn't a clear intention from the mutagen developers to create a Python 3 version of mutagen. One of the main developers said he disliked Py3 and there wasn't much enthusiasm.
That was the situation when I started this project in July. At that point, I intended to just create a Python 3 version of mutagen, with all outdated code replaced. Since then, the original mutagen project has dropped support for Python 2.4 and 2.5, and started looking at creating a Python 2/3 compatible codebase.
When I heard this, I decided there wasn't much point in making a Python 3 only version of a library which would eventually be Py2/3 compatible, so I changed my goal. Now I'm working on making my port work with Python 2, so that I can feed back my changes into the original project.
The eventual aim is to make mutagen and mutagenx identical again. And then, once that's done, I plan to work on some more experimental stuff using the new mutagen as a backend.
For each future release of mutagenx on PyPi, I will renaming the module back to mutagenx in a separate tag. In the main tag here, it will be called 'mutagen' so that I can share source files between the two projects.
If you're trying to make a deb package, I'd suggest using one of the released tags and not the main working tag. Alternatively, use the main tag and rename all 'mutagen' references to 'mutagenx'. However, the main tag might not always pass all the tests.
For now (and probably in the future too), all releases of the project should use the mutagenx name. It is still distinct from mutagen, at least until my changes get ported back.
excellent - thanks.
I've already done just as you said, keeping the mutagenx convention for the debian package produced from an earlier version.
BTW - I'm using this for the users of my Rhythmbox plugin CoverArt Browser here:
- https://launchpad.net/~fossfreedom/+archive/rhythmbox-plugins
- https://github.com/fossfreedom/coverart-browser
MutagenX 1.22.1 is now out - https://pypi.python.org/pypi/mutagenx
I've changed all of the "mutagen" references back to "mutagenx" for release, so you should be able to use it as before. This version has full support for Python 2.6, 2.7 and 3.3.
Always good to hear that someone finds this useful! I use Rhythmbox myself, so I'll take a look at your plugin sometime.
All Python 3 compatibility changes are now in Mutagen. The only remaining things to go across are trivial improvements I made here and there.