[Council] Open letter of support for Python on the Maemo/MeeGo platform
 

After receiving feedback from the community, including developers who are trying to get their software into Ovi Store, it is the opinion of the Council that the unexplained restriction on dependencies between Ovi and Extras - and in particular the availability of Python as a platform for Ovi Store applications - represents a serious threat to the success of Maemo, MeeGo and Ovi Store.
It will come as a surprise for many community members and users that
Python is still not an officially supported language/runtime on the Maemo nor
MeeGo platforms, despite the huge number of* Python applications currently
in Extras, and even though they base on the work of Nokia's own PyMaemo
team, plus two Qt bindings and a GTK+/Hildon one. To put things in
perspective, about a third of ALL stable Maemo applications are written in
Python, both overall and those using Qt.

The community level support means Python itself is located in community
repositories, and, as a consequence, Python software is not admissible to
Ovi (regardless of being free or not). Highlighting this is part of a broader
agenda - ensuring cooperation between libraries and runtimes used by
Ovi-distributed software and software in community repositories, but the
first step towards that is addressing the single biggest such case - Python.

If there are technical issues which need to be addressed, let's discuss
them in the open and try and solve them; if there are purely political
issues, we strongly urge Nokia to reconsider.


Maemo Community Council



Link: Original article.

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

Well said indeed. Add to that the fact that despite early announcements, PySide is still trailing far behind PyQt...

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

Ovi store applications (at least the paid ones) can't depend on extras because extras is not in control of Nokia. Stuff in extras can break any time, and Nokia would take the flak from third party developers that lost income because of the breakage.

For a dependency to be kosher for ovi store apps, it needs to be manually moved to Nokia repository.

I'm not sure what would be the best situation for Qt apps at the moment, since we have PyQt (GPL) and PySide (work in progress). As for pygtk / hildon libs, I think they should just be "frozen" and moved to the nokia repository.

For MeeGo, I think there is ample time for PySide to become ready. PySide is doing some nice stuff currently, like wrapping MeeGo Touch and mobility apis.

PS. Please send a pointer to this open letter to maemo-devel.

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

The problem is that a good part of these packages ARE maintained by either people in Nokia or their subcontractors, just have no official status (see PyMaemo, PySide, etc). For packages not maintained by Nokians directly, I understand your point - but the idea is just to explore how we can deal with this split better, not just that "Extras should be allowed" per se. It's about working out a protocol how packages (mostly libraries) can get to be used from both Extras and Ovi without a lengthy tug-of-war where (looking from the outside) both ends are pulled on by Nokian affiliation.

PS. Forwarding to list

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

Well, as it is these applications need to graduate to the Nokia repository (where e.g. Qt Mobility sits ATM). This will kill normal evolution of the package on extras side, so if the package will continue evolving the "extras" instance of the package needs to be renamed to -experimental or somesuch and the library files installed in a different directory.

What we need is a process how we choose what packages we will "bless" to the nokia repository, and when. If it's currently just a handful of packages, we can go through an accelerated "special case" process and request this from the guy that has the power to do this. If we need an ongoing process, Community Council may be the instance that could request packages to be promoted there every now and then.

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

Agreed. We already did this the hard way with libqt4-maemo5, were lucky enough to spot and react in time with regard to the Web Runtime, but it could be beneficial if we could make that into a policy (it's a sort-of-recommendation now).

Yes ! That is exactly what I'm talking about - we already had complaints people getting turned down from Ovi because of this - now, the thing is that we from *here* do not know which libraries are needed for people wanting to go through Ovi. That's why we feel we need a less ad-hoc process (ideally, get a report of the most requested Extras packages because of which Ovi acceptance failed, or a clear Q&A point in Ovi that tells people that they can come to us and at least ASK for a certain package they might need - and then we can see who is the maintainer, if that is a 'Nokian' package or not, whether it is feasible to push it to the blessed repos down the line, etc, etc).

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

It amazes me that we have to fight this hard for Maemo allowances at this point in its lifecycle...

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

And the second missstep is the requirement of the VAT Number ... this is a huge mistake ... not all type of company have a VAT number ...

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

I don't think this is the case anymore. Individuals can publish on Ovi store.

Re: [Council] Open letter of support for Python on the Maemo/MeeGo platform
 

There is no fight, just something that hasn't been done yet due to technical reasons (ovi store deployment for N900 is not an entirely finalized process).

EDIT: I mean there is no fight *yet* ;-). Of course Ovi store or fremantle platfom guys can still object. But I haven't heard anything that suggests there would be a "strategic" decision not to do this.