SABnzbd Forums

re: http://forums.sabnzbd.org/index.php?topic=69.0

I was unable to reply in the old topic.

Whatever happened to this? I know shypike keeps mentioning setup.py being used to distribute modules, however, other ports such as hellanzb do use setup.py.

UNIX variants such as FreeBSD, OSX, etc rely on setup.py or atleast a Makefile. Makefile would be great too.

We prefer not to install SABnzbd as a Python module, because it isn't.
It's an application which happens to depend on Python (and a few Python modules).
For more on this see: http://sabnzbd.wikidot.com/unix-packaging

Installing SABnzbd is so easy.
Just make sure you have already installed:
- Python 2.4 or 2.5
- yEnc (optional)
- Cheetah
- pyOpenSSL (optional)

After that just unpack the tar.gz distribution file and start using it.
There's nothing to "make".

I'm still not sure you understand the concept of the UNIX file architecture standard.  You don't just copy all the files to a place. There's a bin directory, a lib directory, manual directory etc.

See: http://en.wikipedia.org/wiki/Filesystem ... y_Standard

For interest, the installation you advocate would only fit one *nix that I know of, and that's GoboLinux (which is mentioned in the wiki). Their take on the file system is interesting, but  doesn't seem to be catching on.

See: http://gobolinux.org/index.php?page=k5

We're not particularly interested in Linux/Unix architecture, there are just too many variations.
We distribute a useful package that's easy to install in user space, not in system space.

Fortunately there are people like JCFP who convert our source distribution into a
a standards-conforming Debian/Ubuntu package.
See: https://forums.sabnzbd.org/index.php?topic=387.0

As the port maintainer for the FreeBSD port I was fine to do it once. I was going to write the port for OSX too, but since you obviously have no interest in having ports for UNIX, I'm not going to bother.

Usually maintainers of a program have a personal interest in seeing acceptance for their work. I can't imagine why you don't have an interest in making distribution easier.

You mention that there are too many variations of UNIX architecture, but that's simply not true. The FHS with very rare exceptions such as GoboLinux is the one and only architecture that's used.  It is true that the actual install locations within those vary. For example, osx uses /opt/local while others may use /usr/local but the principle is still the same.

If every one had the attitude about installations and packages that it's "so easy to install" then packaging management tools would be a nightmare, and there would be no standard.

What would it take for you to consider a better distribution mechanism? Someone to submit a patch to make it easier?
All it takes is one person to write and maintain something like setup.py or whatever, and then the burdon for several people, me, JCFP  and any other future and present package matainers would be made much easier.

eydaimon wrote: What would it take for you to consider a better distribution mechanism? Someone to submit a patch to make it easier?
All it takes is one person to write and maintain something like setup.py or whatever, and then the burdon for several people, me, JCFP  and any other future and present package matainers would be made much easier.

If you want it, do it or tell us what to do. The reason we're in Jaunty is because jcfp started an Ubuntu repository and worked as a mediator between us and Ubuntu's licensing guys to get everything worked out. The reason we have an official OSX build is because raf started releasing OSX builds, and we worked with him to get them tested and released alongside the other builds. We apparently have a FreeBSD port because you wanted one. If you want a setup.py, show us what we need to do to help you, because otherwise we're content with what we've got.

The reason you don't see us going through the effort ourselves to do all the package maintenance is because if what I've seen from jcfp's efforts with Ubuntu and Debian, being a package maintainer is a job in itself. And it's an admirable and very important job, just not one I personally want to be involved with, it would drive me nuts. If we tried on our own to release builds for Debian, Ubuntu, Fedora, SuSE, *BSD, etc etc etc we'd never get anything done on the actual app.

This is a totally acceptable attitude and one that I fully understand. However, it seems inconsistent with what shypike has been saying, which is, we can be summed up as "will not cater to UNIX, and we will not have setup.py because we're not installing a library".  For me, if I make a setup.py, then I know two distributions would benefit and those two ports would be very easy to maintain. I'm sure this holds true with other distributions too, so it is worth it for me to do it. However, I'm very hesitant to do it based on what I'm hearing here.  If I could have the same commitment from shypike also, then that would make me feel like it's worth spending the time on.  There's nothing worse than making patches only to have them ignored.

eydaimon wrote: This is a totally acceptable attitude and one that I fully understand. However, it seems inconsistent with what shypike has been saying, which is, we can be summed up as "will not cater to UNIX, and we will not have setup.py because we're not installing a library".  For me, if I make a setup.py, then I know two distributions would benefit and those two ports would be very easy to maintain. I'm sure this holds true with other distributions too, so it is worth it for me to do it. However, I'm very hesitant to do it based on what I'm hearing here.  If I could have the same commitment from shypike also, then that would make me feel like it's worth spending the time on.  There's nothing worse than making patches only to have them ignored.

I don't think we've ever outright ignored a patch. Sure, there's stuff we've backburnered or proposed would work better as a plugin for a later release (like Avahi/Bonjour support), but I don't think we've ever rejected or ignored stuff.

As for the whole "necessity" of setup.py, if we hold the belief that setup.py really isn't necessary, it may be because we just haven't come across an example where it is absolutely necessary. If you feel you have come across an example where it's necessary, then it would be super cool if you would share with the class.

I think you're misunderstanding shypike, though. It's not that we won't cater to UNIX. The problem comes in trying to implement specific support and release specific builds for every packaging system and every distribution under the sun. That's something we just don't want to get into. We're a very small team, and we don't have time internally to do much more than the source release for UNIX/Linux. However, just like we were more than happy to work with jcfp to appease the Ubuntu Licensing Gods, if you've found some panacea that will make the lives of potential future package maintainers easier, we'd love to hear the specifics.

inpheaux wrote: if you've found some panacea that will make the lives of potential future package maintainers easier, we'd love to hear the specifics.

Both FreeBSD and OSX have tools included in the ports system which make dealing with standard distribution of programs/libraries such as those using setup.py a breeze. i.e. for the port itself, it will auto detect setup.py and know exactly how to install the package just because it's so common. The same goes for the standard configure/Makefile type distribution for C/C++/etc apps, and same again for perl's Makefile.pl.  I imagine other distributions and Unixes (Unicies?) also make use of common installation methods and have automated this heavily to make it really easy.

For OSX (as for win32) there are 2 possibility for using SABnzbd :

- binary (.app) : include python interpretor and all dependencies
- sources : all dependencies have to be installed

The setup.py included in sources is used to generate binaries (for OSX, Win32) and create a clean sources tar.gz. It's not used like in ports...

rAf: there's also macports which some users (like me) prefer.

In your case, setup.py probably doesn't make your life easier, but I'm pretty sure it does for many other packaging systems.

I understand what you mean.
For now, setup.py take arguments (from memory) app, bin, src.
it should be possible to implement an 'install' argument for ports like repo or rename the setup.py in build.py and make a proper setup.py...

The setup.py in the SVN archive has the wrong name, it should be called build.py or package.py,
since it's only used to create the current distribution packages.
To support your wishes, we would need to develop something new altogether.

As it is, we have no intention to develop our own Linux packages.
It would just be a regular Python module distribution method.
Unfortunately there's no single method for that either 

no one is expecting you to develop your own Linux packages.
The regular distribution method *IS* setup.py. I'm not sure why you want to deviate and call it something else.
Having setup.py will make it easier to distribute because it's already conforming to the standard. I'm sure the developers of hellanzb aren't crying at night because they release with setup.py.


I'll give you examples of how distributions are using common distribution methods. Here's the macports for setup.py:
http://guide.macports.org/#reference.po ... thon.sugar

And here for freebsd:
http://www.freebsd.org/doc/en_US.ISO885 ... ython.html


It can be something else, but default is setup.py, because that's the most common mechanism.

Also, if you read about setuptools, there is nothing indicating that it applies to modules only:
http://pypi.python.org/pypi/setuptools

"Download, build, install, upgrade, and uninstall Python packages -- easily!"

python packages can be anything python related.