The Return of setup.py

[shypike]

I'm not sure why you want to deviate and call it something else.

Read carefully.
What I wrote is that OUR setup.py doesn't do the regular thing.
It actually creates OSX-binaries, Windows-binaries and the source tarball.
Our setup.py (which should be called package.py) creates a tarball that (you would like to) contain a regular setup.py.

The regular distribution method *IS* setup.py.

Not true: setup.py is the standard installer for Python source distributions.
It's just that we chose not to provide one.
And we would still need something to create the tarball.

There's a personal stroke in this. I consider the way Python apps are typically installed just bad design.
I find it hard to swallow that people think it's a good idea to install an application into the Python installation itself.
How do you run two versions of an app that way?
Although I like the language itself, I'm unimpressed by it's development environment.

Having said that, I'll see if I can motivate myself enough to cobble together some setup.py.

[eydaimon]

I don't mind writing the setup.py if you tell me what you require of it  besides installing the app. Is creating the multiple distribution packages the only requirement?

[shypike]

The new setup.py should install the unpacked content of the tarball on the system.
setup.py will be part of the tarball.

The current setup.py has been renamed to package.py and will keep its current purpose.
End-users do not need package.py.

[eydaimon]

ok, that makes perfect sense. So do you want me to go ahead and look into it, or is it something you'll look at? I'm going to be unavailable for a couple of weeks.

[shypike]

It would be great if you could do it some time in the future.
I will have a look at it, but currently it's not a high priority for me.
There are plenty of other problems to sort out.
Should you start working on it, drop me an email.

[carresmd]

For personal and educational use I wrote (or copied from the tutorial) a setup.py for SABnzbd. I've used it to build a (my very first) Debian package from the SVN code for our team (testing purposes). And I've also used it to build a Fedora package. It's quite useful for automating the packaging process, to some extend.

However, I'm confused why it would be wrong to have SABnzbd installed as a Python module. As far as I know (just started learning Python et all) all software written in Python IS a Python module/package. But you can install to i.e. /usr/share/ (which is what I've done), which, if I understood correctly, keeps it from registering as a Python module as the path isn't in the Python search path.

I don't know if eydaimon has started doing stuff or whatever. But I just wanted to put in my opinion/vote (or whatever).

[shypike]

My personal opinion is that the Python package system sucks for applications.
SABnzbd is an application that just happens to need Python.
I don't how it would improve things when it's integrated into the Python interpreter.

There are some practical reasons too.

We carry our own copy of CherryPy, because different CherryPy releases tend to
be very incompatible. When you install SABnzbd as a module, there's no way
we can have our own CherryPy without also modifying the imports inside CherryPy.
(At least, I don't know it).

When developing SABnzbd we need to test outside the Python environment anyway.
Also creating the Windows and OSX apps, integration into Python would be very awkward.
So the only users "benefiting" from integration would be Unix package creators.
If a package integrator insists on doing it the Python-way, that's fine.
Only we're not going to put effort in supporting this particular use.

[carresmd]

My personal opinion is that the Python package system sucks for applications.
SABnzbd is an application that just happens to need Python.
I don't how it would improve things when it's integrated into the Python interpreter.

Like I said in my previous post, when _not_ installing to prefix/lib/pythonX.Y/site-packages, exec-prefix/lib/pythonX.Y/site-packages or somewhere else in Python's search path, it's not installed as module and/or part of Python.

There are some practical reasons too.

We carry our own copy of CherryPy, because different CherryPy releases tend to
be very incompatible. When you install SABnzbd as a module, there's no way
we can have our own CherryPy without also modifying the imports inside CherryPy.
(At least, I don't know it).

I think this wouldn't even become a problem when SABnzbd is installed as a module. It would just become a module under SABnzbd (I.e. sabnzbdplus.cherrypy). But when you aren't installing SABnzbd into Python's search path (I.e. /usr/share/sabnzbdplus), this wouldn't become a problem in the first place.

When developing SABnzbd we need to test outside the Python environment anyway.
Also creating the Windows and OSX apps, integration into Python would be very awkward.

I'm not sure how the Windows and OSX packaging works. But I think there's some room for customization how setup.py does it's work, so *nix code could be kept apart from the OSX and Windows code.

It might also be possible to just add a *nix segment to package.py and build system specific packages for the most mainstream distributions.