Re: Namespace conflict for python-magic
Mathias Behrle wrote... > So finally I am still quite undetermined what to do to get the actual release > of relatorio packaged[5] (it will be needed for the next release of Tryton). > For > now there is only one usage of python-magic[6], so probably best to patch > relatorio for now to use file-magic... Since I doubt it's super-urgent, just wait a few weeks to see what's going to happen. In the best outcome, this issue will resolve itself within the next weeks. Another idea was to add a compability layer in Debian, probably by switching to PyPi and providing glue code for the users of the file(1) version. Since to me it seems PyPi is the saner implementation, CMIIW. Worst approach: Ship a code copy. Appearently kopanocore, peframe and sqlmap already do that. You'll have to clean up afterwards, though. Chri- "The delivery of good medica^W packaging is to do as much nothing as possible" stoph signature.asc Description: Digital signature
Re: Namespace conflict for python-magic
Mathias Behrle wrote... > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep 2017 > 19:38:56 +0200): > > The cleanest solution indeed was to bring both upstreams together and > > ask them to reconcile the APIs and eventually make one of the both > > implementations obsolete. As things happen such an attempt was started > > two years ago but appearently never came to a result.[1] > > Agreed, that this would be the cleanest solution, but as you say there is > little probability, that the two upstreams will work together to merge their > implementations. Still this should be tried first. Also, I'm not that pessimistic, see below. So let's bring the parties involved into the loop: Hello * Christos Zoulas for file(1), and * Adam Hupp for python-magic. A while ago, almost two years by now, there was a short discussion on the file(1) mailing list concerning a merge of the libmagic python bindings. In summary, Adam proposed to end the long-standing confusion[2], Christos agreed and suggested a possible solution[3]. After that however, nothing visible happened. But now I'd like to give that idea a push. Mostly since on the Debian Python mailing list (also in Cc:) a proposal was made to exchange python-magic in Debian, from the file(1) to the PyPi one. Wearing the maintainer's hat for file(1) in Debian, I opposed this for the sole reason this will break applications that rely on the file(1) version. Resolving this issue upstream will bring benefit for everybody, even at the risk of a bumpy but one-time only transition. What is the status of your project? Do you need some input, suggestions or other incentive to finish this project? Cheers, Christoph > > [1] The file mailing list server is currently down, so I cannot provide > > URLs. The Message-IDs are > > > > <20151020133008.9b79517f...@rebar.astron.com> > > Still down:(, If you could provide some content for me that would be nice. Certainly: [2] [ Adam: ] (...) | Sadly, this has led to regular confusion for our users. I'd be happy | to shutdown my version to avoid more confusion but it seems to be | fairly widely used (200k downloads from pypi last month). It also has | a number of fixes for various issues: libmagic bugs, thread safety, | support for other platforms, etc. | | I'd like to gauge interest in merging these bindings into a single | codebase. Specifically, this would mean: | | - merge magic.py from each package to produce something reasonably | close to API-compatible to both, with some methods marked as | deprecated where it makes sense. | - the merged package would live under the python-magic name in pypi | and in the `file` source distribution. | | I think this would be ideal for everyone involved, but wanted to gauge | your interest before I went to the trouble. (...) [3] [ Christos: ] | Sure, it would be nice for the users if there was a definitive | python package that had the best features from both. Someone recently | filed a bug report about it: http://bugs.gw.com/view.php?id=477. | Why don't you go ahead and merge them and I will copy the result | over mine, and put a link to your package in the file sources (or | even delete mine, and put a link to your package). signature.asc Description: Digital signature
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep 2017 19:38:56 +0200): > Mathias Behrle wrote... > > > Current python(3)-magic in Debian is built from source package 'file'[0]. > (...) > > OTOH the package providing python-magic on PyPi[3] is provided by another > > Upstream[4]. > > ... and I assume the APIs are not identical? Indeed. > > The cleanest solution for me would look like > > - package file in Debian should provide python(3)-file-magic > > - python-magic should be the package name corresponding to the PyPi package > > python-magic[4] > > This would result in users of the current python-magic (from file) would > be forced into the other one. Unless we (as in Debian) can guarantee > this will work in each and every use case, I fail to see why this should > be considered a clean solution. When saying clean solution I talked about the solution inside Debian. I think it could be made to work, but the result doesn't justify the effort and still wouldn't solve the conflicting namespace. > The cleanest solution indeed was to bring both upstreams together and > ask them to reconcile the APIs and eventually make one of the both > implementations obsolete. As things happen such an attempt was started > two years ago but appearently never came to a result.[1] Agreed, that this would be the cleanest solution, but as you say there is little probability, that the two upstreams will work together to merge their implementations. > Trying to address this conflict in Debian is always only second best. If > this is the only feasible way, it still should leave a choice to users > so they can install the implementation of their own preference. Co- > installability of both package was certainly nice-to-have but will > probably impossible for technical reasons. It is indeed an ugly mess. For me both packages must be co-installable, because the relative rdepends must be usable at the same time. Reading through the issues of python-magic (as on PyPi) the problem of course dates from the very beginning[2], spans multiple issues[3] with currently still open this one[4]. So finally I am still quite undetermined what to do to get the actual release of relatorio packaged[5] (it will be needed for the next release of Tryton). For now there is only one usage of python-magic[6], so probably best to patch relatorio for now to use file-magic... > [1] The file mailing list server is currently down, so I cannot provide > URLs. The Message-IDs are > > <20151020133008.9b79517f...@rebar.astron.com> Still down:(, If you could provide some content for me that would be nice. Cheers, Mathias [2] https://github.com/ahupp/python-magic/issues/21 [3] https://github.com/ahupp/python-magic/issues/57 https://github.com/LibreTime/libretime/issues/166 ... [4] https://github.com/ahupp/python-magic/issues/33 [5] http://hg.tryton.org/relatorio/file/tip/setup.py -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpzVN9Y5Z4tC.pgp Description: Digitale Signatur von OpenPGP
