PortableApps.com wins big in the 2009 Community Choice Awards and hits 100 million app downloads!

Codifying Some Support

Submitted by OliverK on September 11, 2009 - 11:26pm

I don't know if anyone is keeping up with the gVim thread, but I posted about something that I thought the Release Team should handle (or at least consider). As I posted here, http://portableapps.com/node/15654#comment-126364, I thought the the release team should formalize where the whole Perl\Python\ruby, etc debate.

*Perl*
I'll start with perl as I butcher it quite well. There's two Perl releases in the forums currently:
Shawn Fauchers
daBomb69 's
Shawn Faucher's version places the bin\lib\site of Perl in Common Files. daBomb's goes in App\Perl for the binaries. Neither of these will function with XChat's perl plugin, which requires ActiveState ActivePerl. Technically a third version of perl. Strawberry Perl also released a portable version
.

*Python*
There's technically two version of Python in forums, although one has been declared defunct by it's author. I can't really comment on this one, since I'm not sure how exactly the whole thing works.

Personally, I'm evenly split on the issue for Perl, as well as Python. I don't think Python support can be cut up the way Shawn did Perl. I know Java runtimes are in CommonFiles, so I would think that its appropriate for Python and Perl runtimes (along with others) to also be there. However, that brings in the issues of asking developers to change the way they are handling distributions, which I don't think would be greeted with exactly open arms.

I know I am not for doing multiple copies of everything by every app. Even though flash drives are ridiculously cheap these days, I still don't think we should squander that space that could be used for something else. I think that it would also increase download sizes, which is unnecessary. Especially if we have the something like gVim being bundled with 5 different languages.

Perhaps the only exception is something like XChat, but I don't think that XChat is going to be released . . . In that case, we could probably do addon installers of some sort.

John, I don't know if you have a plan here or not. If you do, I'd like to know. I think that the issue will become greater as more IDE's and other things are (hopefully) introduced, and that it would be nice to be dealt with now.

( categories:

General Discussion

)

Python

Chris Morgan (Homepage) - October 28, 2009 - 1:25am

There, I finally got round to finishing this for you, Oliver. Remember how I told you that I just hadn't quite finished it a few weeks ago after leaving it for a couple of weeks? Well, this is about seven weeks overdue. Enjoy it

Distributions: only the official distribution is used much... although "ActivePython is the industry-standard Python distribution" it doesn't get used much where with other languages the ActiveState edition does.

Versions: There are then three versions used often, 2.5, 2.6 and 3. 3.x is incompatible with 2.x (lots of new language things, various things broken), and some applications stay with 2.5 because it's easier (e.g. Blender and Inkscape both use 2.5 IIRC, and BPBible still uses 2.5 because it works fine, and new SWIG bindings for SWORD would need to be compiled for 2.6, which would require updating the bindings as well, et cetera ad tedium). You'd need different packages for different versions (e.g. CommonFiles\Python25 and CommonFiles\Python26 or possibly CommonFiles\Python\NN).

Different package types and distribution methods: there are three main ways of doing this; different applications use it different ways.

PythonNN.dll - a single DLL from the Python distribution (a subset of the below options). This is used in gVim with Python support.
py2exe - here a Python application is compiled. Most Python applications are distributed this way. BPBible and Task Coach, for example. These have an executable, various DLLs and other related things (there are two ways of making py2exe'd applications smaller, by making it 'compress' all that stuff into a "library.zip" file, and then 'bundle' that into the executable which launches it all; BPBible is the only application which uses either, as part of its [official but not stock] PortableApps.com build, all others use stock builds). In theory these could all be changed from using py2exe to using a full Python distribution, but there are problems with it. BPBible, for example, checks to see if it has been fed through py2exe, and if it has, hides the debug menu unless -d was passed. Applications could be made to behave completely differently when py2exe'd from when in source. We could set up a fairly simple override here for places it matters, but I think we're unlikely to do this at least until we go with cross-platform things and having the Python source (something or other which I can't remember what I was going to type)
Standard Python binaries - used in Inkscape and Blender. Standard Python binaries are included (generally with some fairly pointless files stripped out), but there is an issue with making these common.
- Fixed locations - Inkscape currently requires that its Python build be in ./python (relative to inkscape.exe). Others like Blender support an environment variable for it (Blender Portable stores its Python in App\Python25 from memory). This isn't a problem for real Python applications like Task Coach or BPBible; they will be happy run with Python in any location.
- Extra libs - they've got to be able to add things to Lib\site-packages (and other spots in Lib), without clashes, and be able to uninstall them too (the biggest problem, you'd need a "shared libraries" registry of some sort). I think that this is the biggest killer with using a shared Python distribution - different "extras".

I probably had some other things I was going to say but I think you've been patient enough

Christian, developer, moderator

Applications

User login

Follow & Connect With Us

What is a portable app?

Sponsored Links

Codifying Some Support

Python