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

Tue Nov 27 22:34:21 UTC 2007

Stani's Python Editor wrote:
> 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.

Let's see if we can get this in the upstream source tree.

> 
>> 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.

Sounds good to me. Where should this be changed? (I feel stupid asking this
question :-) )

>>
>>>> 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?

Right. I did it before removing winpdb from the plugins folder. I've updated it.
I haven't removed the plugins/spe_$someplugin.py files. That's fine, isn't it?
(attached a new patch).

> 
>>>> 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.

That's great. Thanks a lot for this!

Take care,
Emilio

> 
> Best regards,
> Stani
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/python-apps-team/attachments/20071127/89ce84dd/attachment-0001.pgp 