Python AppStore / Marketplace

[Paul Boddie]

On 22 Feb, 12:24, Marcel Luethi <marcel.lue... at gmail.com> wrote:
>
> Using my iPhone I suddenly realize how easy it is to find applications
> in Apple's AppStore. How easy and fast it is to install or de-install
> an app. My iPhone even checks in the background if there is an upgrade
> which could be installed painlessly.

Yes, but this is just one platform. Can you download these iPhone
applications onto Android devices and use them? How would you package
your Objective-C (or whatever Apple has mandated) software for Android
or Debian or anything else out there?

> Then I see VMware's Virtual Appliance Marketplace, where you can
> download already pre-configured "appliances" for all kind of stuff.
> You can even download a basic appliance, install and configure your
> servers and tools - and upload it again, so that others can profit of
> your work.
>
> Unfortunately there's nothing like this in the Python world...

That's because you first wrote about platform-specific packaging and
now you're writing about language-specific packaging. And it's not as
if the former area hasn't been well addressed by Free Software,
either, but I suppose that's another discussion to be had.

> My idea: what about having a beefed up Cheeseshop for Python apps and
> an accompanying client app kind of iTunes for Python apps?
>
> The server side could be easily implemented with any of the current
> web frameworks. It's simply a management platform for the app packages
> (descriptions, versions, platforms, licenses, user's comments, number
> of downloads, ...) and the package files themselves.
> It should be definitely hosted by the PSF I think.

Well, what you're proposing risks exactly the same problems that many
other language-specific packaging solutions suffer from: it starts off
with specifying platforms, dependencies (which you didn't mention),
download files, and ends up with the user downloading huge amounts of
stuff that may already be on their system, mostly because such
solutions assume that the system doesn't really know anything about
what's already installed. Consequences of this may include a lack of
decent system-related tools to manage the result of installing stuff:
it would be like your iPhone application being installable on Android
by being dumped into the filesystem with little regard for existing
content and with no obvious strategy for safely removing the
application later.

It's true that there are other application repositories similar to the
VMware service you mention which don't really care about dependencies
and just offer self-contained applications for reasons of catering to
the lowest common denominator, and perhaps there's a desire to have
such services out there, but then again, doing such stuff specifically
for Python will lead you into making self-contained applications using
those "installer" technologies, or at least mapping and providing non-
Python library dependencies across multiple platforms. Or you could
just make it easier for Python projects to provide self-contained
applications based on VMware or Free Software alternatives - at least
that would allow you to focus on one platform, although the result
wouldn't be regarded as a "fully integrated" cross-platform approach
because a virtual machine would be involved.

> The multi-platform client should be intuitively and elegantly allow
> app browsing, downloading and installing those Python apps. In that
> respect it is sort of a Linux package manager (Synaptic, YUM, ...).

Why wouldn't you make use of existing system package management, then?

> But this is only the end-user related stuff. Furthermore it should
> allow to create new apps (probably based on a previously downloaded
> base app), package and upload them again (kind of Google AppEngine
> Launcher). Those base packages should include some basic management
> framework (for installation and configuration) and hopefully soon
> after the release of this platform they will be created in a broad
> variety to allow app developers to choose among many Python-version/
> platform/GUI/...-combinations.

Well, system packages of Python software typically make some use of
distutils to put files in the right places before bundling those files
together. The resulting system packages then work within a "basic
management framework", although I accept that there typically isn't
much support for trivial repackaging, although it isn't that difficult
to repackage, say, a Debian package and to publish it in your own
repository.

> IMHO an architecture like this would greatly enhance the productivity
> of the whole Python community by capitalizing the knowledge of many
> Python specialists. I don't have to find/install/configure all the
> basic stuff myself (see above) to build my app. But I can concentrate
> on my app because I'm standing on the shoulders of giants.

It isn't hard to find/install/configure the basic stuff in most GNU/
Linux distributions, either.

> I believe it also would make Python as a great platform more visible
> to the world - because there is only one place you have to go...
>
> What do you think???
> Is this crazy??? Or simply stupid?
> Or is this the way to world domination...? ;-)

Some people - usually Windows users - seem to like the idea of a
Python-specific solution, whereas others look to be able to administer
packages of many different kinds of software on their own system, and
in some environments people look to be able to administer packages for
many different kinds of system, at which point the Python-specific
interest becomes very small indeed. Generally, one has to choose one
of these levels and work mostly at that level when dealing with
packages, and I would argue that the best level is that of the system,
making language-specific solutions fit inside the facilities (and
restrictions) of the framework provided at the system level.

I think there is some merit in allowing people with a Python interest
to follow new developments (as can be done somewhat with the Package
Index) and for references to system-specific packages to be
incorporated into such a service. At one point I started writing a Web
application to do this, but instead of focusing on manual editing of
package details, it would be better to link the package records to
other services which make the actual system packages available. There
could also be unofficial build systems which provide such system
packages ahead of the usual operating system distribution release
schedule that people often complain about (in that they don't get the
latest stuff quickly enough).

For example, you'd have a package record like this:

  Name: XYZ
  Platforms:
    Debian: http://debian.package.server/python-xyz
    Windows: http://windows.package.server/python-xyz

Maybe you'd delegate the versioning and architecture availability to
the specific platforms.

> Unfortunately I'm not expert enough to build such a system - but if
> there is enough interest in the community I gladly would like to help.

There is ongoing work on packaging-related matters. Perhaps you should
subscribe to the catalog-sig or distutils-sig mailing lists (see
mail.python.org for details). That said, I'm skeptical about language-
specific packaging precisely because of the reasons given above, and
to make my own Python libraries and applications work within the
Debian mechanisms is something I've learned to do. Since that is all
that really matters to me, I don't see that much benefit in learning
something more sophisticated for Python which does less in my own
environment, which I consider to be the operating system and not the
language technology.

Paul