search

pR0Ps / zipstream-ng

A modern and easy to use streamable zip file generator
https://pypi.org/project/zipstream-ng/
GNU Lesser General Public License v3.0
21 stars 6 forks source link

Drop-in replacement means the original zipstream cannot be installed in parallel #9

Open baldurmen opened 2 years ago

baldurmen commented 2 years ago

Hi,

At the moment, since you are declaring packages=["zipstream"] in setup.py, in the Debian package I maintain, files get installed in /usr/lib/python3/dist-packages/zipstream/.

This means one could not install the original zipstream package and zipstream-ng in parallel. This could be problematic if for some reason there was a compatibility breakage between the 2 versions.

I understand this is not problematic if you run things in virtualenvs (as many do), but it is for Debian and other distros packaging this python package.

Was this a design choice? Are you committed in implementing all the possible new features the original zipstream might add in the future?

As far as I see it, it would also be possible to declare packages=["zipstream-ng"] in setup.py and let people decide whether they want to use the original or the ng version :)

pR0Ps commented 2 years ago

zipstream-ng isn't a drop-in replacement for any other zip streaming libraries so unfortunately a compatibility breakage is pretty much guaranteed. From a Debian packaging standpoint, I guess the package would have to declare that it "conflicts" and "replaces" the other package(s), but doesn't "provide" them.

I originally made this library because I wanted something that could generate zip files on the fly while also being able to calculate the final size up-front. My goal was to build something to completely replace the myriad of other zip streaming libraries feature-wise, while improving on their APIs and fixing bugs. I liked the zipstream name and because I was envisioning it as a total replacement, I didn't consider it an issue that it conflicted. Unfortunately this has caused some problems in the past that had to be worked around, as well as this issue.

Changing the package name is possible (I quickly prototyped changing it to zipstream_ng here), but would be a backwards-incompatible change. This would involve pushing a new major version and updating any projects that use the current version before the Debian package could even be used. Also, subjectively, I like how from zipstream import ZipStream reads more than from zipstream_ng import ZipStream. All things considered, I'd rather to keep the package name as-is.

As far as I know this library has all the features of the other packages and I'm committed to keeping it that way (within reason). If you know of projects that use the conflicting python3-zipstream Debian package I'd be more than happy to submit PRs to them that swap the existing dependency to this library (if they're open to it).

baldurmen commented 2 years ago

Thanks for the clarifications.

I do believe the best and cleanest solution would be to change the namespace to zipstream_ng and make a new major version breaking backwards compatibility. It sucks and I understand why you would prefer not to do this, but this library is relativity young and the work needed by projects using it would overall be pretty small.

I understand the aesthetics considerations (code is a form of literary art IMHO) but I feel the status quo would bring a lot of trouble in the future and ultimately impair the adoption of zipstream-ng. The current situation in Debian isn't so bad, as the only package depending on python3-zipstream is supysonic, and it switched to zipstream-ng in the latest upstream release. This is why I'm packaging this library.

I don't think asking other projects to move to this library because of a namespace collision is fair either, even if zipstream-ng works better :). People tend to be pretty stubborn over this kind of thing...

Patching things in Debian wouldn't work either, as all maintainers would have to agree to patch their packages to use either python3-zipstream or python3-zipstream-ng. This won't happen, as Debian Developers are also pretty stubborn :)

This would involve pushing a new major version and updating any projects that use the current version before the Debian package could even be used.

As for this, it's not really an issue and I can make things work easily enough while the transition is being done.

Cheers,

pR0Ps commented 2 years ago

The current situation in Debian isn't so bad, as the only package depending on python3-zipstream is supysonic, and it switched to zipstream-ng in the latest upstream release.

I do see the general problem where if you have some packages that use python3-zipstream and others that use python3-zipstream-ng then they can't concurrently be installed on the same system, but as there's currently only 1 package that uses python3-zipstream xor python3-zipstream-ng, there doesn't seem to be an urgent need to change things right now.

I'll definitely keep the name change in mind though. At some point I'm probably going to have to break backwards compatibility anyway so I can revisit changing the package name at that point and do both at the same time.

I don't think asking other projects to move to this library because of a namespace collision is fair either, even if zipstream-ng works better :). People tend to be pretty stubborn over this kind of thing...

I don't know about that - I moved 2 projects that I personally use (OctoPrint and supysonic) to this library primarily because I wanted a progress bar when downloading the zip files they generate. This requires calculating the final size of the zip before generating it, something that the other library doesn't do. Both projects were very receptive to the change. Granted, for projects where knowing the size beforehand isn't an advantage there might not be much of a reason to switch though.