magic.py file collision

[nicfit]

Hi,

I use python-magic in eyeD3 and am quite happy with it, thanks!

On gentoo, at least, there is a package called sys-apps/file that provides libmagic.so and lays down a magic.py in site-packages. This collides with python-magic's file.. Which was first? I'm thinking of patching python-magic at install time to have a different module name. Or.. is python-magic going to replace what is in the 'file' pkg someday?

[ahupp]

Yeah this is an unfortunate situation. I'm not sure which one came first, both are fairly old. IMHO the interface of python-magic (this one) is better and should replace the one shipped with libmagic. I might try to build a compatibility layer, mark the old one deprecated and see if there's interest in merging them. Thanks for the reminder.

[gtback]

There is a similar problem on Debian/Ubuntu. There is a python-magic package (related to file/libmagic), though it is not present in a standard install. For me, if both are installed, the Python path (sys.path) picks up this version of python-magic before the OS-provided one.

I'm almost done with a compatibility layer for this (it uses whichever library is present, and presents a common interface to both), along with the various ssdeep wrappers I've found. I'm guessing that the gentoo python-magic package one is similar, and I can add support for it if not. I'll mention on this thread when I get it posted.

[ahupp]

What kind of interface does the compatibility layer have? I'd rather not introduce a 3rd API.

[gtback]

Sadly(?), the interface will be different. However, it is not so much a compatibility layer as a utility class. It uses properties to calculate various attributes of byte streams, as in the following (were C is the class I'm developing)

c = C(open(...).read())
print c.md5
print c.mimetype
print c.ssdeep

print C("A"*1000).sha1

[ahupp]

Gotcha. It sounds like this is solving a slightly different problem than
the one I'd like to solve (namely, merging the two bindings). I'll carry
on then, thanks!

On Thu, Oct 18, 2012 at 8:58 PM, Greg Back notifications@github.com wrote:

Sadly(?), the interface will be different. However, it is not so much a
compatibility layer as a utility class. It uses properties to calculate
various attributes of byte streams, as in the following (were C is the
class I'm developing)

c = C(open(...).read())
print c.md5
print c.mimetype
print c.ssdeep

print C("A"*1000).sha1

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-9589237.

Adam Hupp | http://hupp.org/adam/

[mitar]

Use virtualenv and your problems will be gone.

[nicfit]

Sometimes it is desirable to have a system install of some python app or lib. That is what we're trying to solve here.

[sebix]

Are there any updates to this problem? Have there been solutions for some distributions?

We are facing the same problem in openSUSE.

[ahupp]

I have an experimental branch that merges the interfaces of python-magic (this library) and the one shipped in libmagic. https://github.com/ahupp/python-magic/tree/libmagic-compat

Want to take a look?

[cazino]

Hi,

Do you have plans to merge the libmagic-compat in master ? It would be very helpful for software maintainers who want to have portability between a debian/stable and a pypi installation for exemple.
Of course I would be glad to provide some help if you need any.

Regards.

[sim0nx]

Hi,

Any possibility you could merge that branch into master and bump the version please?

[akien-mga]

Is there any update on this?

I'm also running into issues due to this conflict between file's Python bindings (pip name file-magic) and this package (pip name python-magic) which both provide conflicting magic.py.

I'm a packager for the Mageia Linux distro and Lutris recently started using this package (python-magic), and packaging it was a headache due to the conflict with file. Now it generates a situation where software that uses file-magic e.g. rpmlint) can't be used together with software that uses python-magic.
Downstream bug report: https://bugs.mageia.org/show_bug.cgi?id=27619

Currently I might hack things around by renaming python-magic's module to python-magic.py and patching Lutris code accordingly, since it's my only packaged application using this module... but it's not a good long term solution.

[jasontibbitts]

Just a note that this has now come up in Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=1899279

[SchoolGuy]

@ahupp So all distros which want to package your code now have this problem due to the naming conflict. Can we somehow help you?

[ahupp]

I forgot to update this issue, but it should be fixed with the compatibility layer shipped on 0.4.20.