[Python-apps-team] Spe's Debian packaging feedback

[Stani's Python Editor]

Emilio Pozuelo Monfort schreef:
 >>> Stefano has created a manpage.   And we have a .desktop file from 
the old
 >>> packaging. I'm attaching them to this mail.
 >> What would be the appropiate place to put them? In a debian folder?
 >
 > A 'misc/' folder would be fine in the source tree.
Ok, I'll do this.

 >> Concerning wxGlade, I have contacted the packager and asked him to
 >> update the package. He did, but now it is probably waiting approval
 >> somewhere to get pushed into the repository. I was wondering if the name
 >> of the package python-wxglade suggests it is a library, while it is an
 >> application?
 >
 > We have now 0.6.1 in the archive. If you mean a newer version, let me 
know and
 > I'll try to get it in.
 > http://packages.qa.debian.org/w/wxglade.html
No, this is the latest release.

 >> With winpdb there  is a small issue. As the winpdb upstream doesn't
 >> contain an __init__.py file. SPE can not know where it is located and
 >> SPE needs to import modules of winpdb for its interaction. I always
 >> added an empty __init__.py myself. Probably you have a more elegant
 >> solution.
 >
 > As Bernd said, it works fine in Debian (and so does in Ubuntu). :-) 
And in case
 > you remove it, it will work fine here, and I'd say in other distros which
 > include the module.
Thanks Bernd for confirming this. I just wanted to be sure.

 >
 > Ok, I've downloaded the pychecker source package and it includes 
pychecker2.
 > I've filled bug requesting its packaging.
 >
 > http://bugs.debian.org/453092
 >
 > I'm curious about your modifications... what kind of changes were 
them? If they
 > are suitable for upstream we could forward them.
I'll come back on this. There are two options: or the patches are 
applied to the pychecker package or SPE has to ship its own customized 
version of pychecker.

 >>> I know removing those plugins from the source tree would mean removing
 >>> some
 >>> functionality from the IDE, but aren't they plugins? So I'd suggest
 >>> you making
 >>> them optional. If the user has them installed, then they will work.
 >>> Otherwise,
 >>> they can't be used. What do you think?
 >> For me it is totally ok to make them external, but I rather prefer not
 >> to have them optional. Most people who use spe, use and expect the
 >> debugger. Making them optional also means quite some changes to the spe
 >> code in order to make all the menu and toolbar icons optional or make
 >> them display a warning "please install...". Right now I am finalising a
 >> public release and don't want to delay it further.
 >
 > Sure, there's no hurry about this, but would be great to have this 
improved
 > sooner or later.
 >
 > I understand your point about the windows users. But there is one 
thing I'm
 > worried about, which is your changes to the modules. Because if you 
do them
 > locally, and we link to the system modules, we won't have the same 
setup, we
 > will have bugs which people using your shipped modules won't have, 
and the other
 > way round, and you could say at some point "my shipped module is 
modified, so
 > WorksForMe" (not saying you are going to say that, but you see my point).
 >
 > So what I'd like to see, if it's possible, is to see that your 
shipped modules
 > are upstream's. No need to do it now, I'm not requesting you to get 
rid of your
 > improvements, but we could see where it makes sense to forward them 
upstream,
 > where it could be avoided changing spe's code... and what is 
necessary and
 > unavoidable.
There is only a modification for pychecker. All the others are fine 
upstream. The change for pychecker doesn't make sense for pychecker on 
itself, but only to interact with pychecker from an external program. I 
don't know if pychecker authors would be open for this.

 > Another thing is that looks wrong to me (I can be wrong, so please 
correct me if
 > I am) is that spe is using the plugins directly from spe's modules. 
Something like:
 > Parent.py:            from plugins.kiki import kiki
 >
 > This means that I have to symlink _spe/plugins/kiki to
 > /usr/share/pycentral/kiki/site-packages/kiki, where kiki is installed 
in Debian.
 >
 > This is not a big issue for us, as it's not difficult to symlink it 
(we are
 > already doing it ;) but it's probably not ideal, and in case you 
create two
 > different packages for windows and linux users, it will mean that 
user who
 > installs spe and has kiki/winpdb/... installed will have to make the 
symlink...
 >
 > Probably moving the plugins to _spe/$name, and doing
 > 	from kiki import kiki
 > would solve it. What do you think? Is this a good idea, and if so, is 
it feasible?
A better solution would probably be to insert the spe plugins folder at 
the beginning of sys.path. If the plugins folder is empty or not 
existent, automatically the external modules will be loaded. If the 
plugins directory is not empty (only on Windows), it will load it from 
there.
 >
 >>> I've made a patch which removes the hashbangs from imported scripts.
 >>> Could you
 >>> please apply it if it's ok? (attached).
 >> I will look into it.
I still need to  look into it, but of course there shouldn't be any 
patches to the plugins (pychecker, wxglade, ...) as I prefer to make the 
delta from upstream as small as possible. Moreover in the case of debian 
only pychecker will be in the plugins directory until we resolved the 
issue. Could you please update the patch to exclude the plugins?

 >>> Stefano has also worked on a setup.py distutils script, although as we
 >>> have
 >>> removed kiki, wxGlade... we want to know what do you think about it to
 >>> remove
 >>> those from the setup.py too (in fact I already did it, but it's our svn
 >>> repository so the one with those plugins is publicly available).
 >> I have a setup.py script which is heavily orientated to windows. I look
 >> how I can best use it.
I will try to merge the two setup.py into one script. On windows there 
is a seperate postinstall script to add shortcuts to the start menu 
(like spe.desktop  on debian).

 >>> Finally, we would appreciate a lot if you could make a tarball
 >>> whenever you do a
 >>> public release!
 >> A public release is not far away. Actually the whole blender python
 >> scripting support for spe got a big facelift and I need to do some more
 >> tests in order not to have a cascade of releases within days. I hope to
 >> keep good contact with the python app team so releasing spe can be as
 >> smooth as possible in the future. I hope we can reduce the amount of
 >> patches for debian to a minimum by fixing things as much as possible
 >> upstream.
 >
 > Agreed :-)
So I first will try to improve spe svn with all your suggestions. Before 
doing the release I would like to see if we can add some improvements to 
make the difference between the debian package and the spe tarball to 
the complete minimum.

Best regards,
Stani