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

Tue Nov 27 11:11:54 UTC 2007

Stani's Python Editor wrote:
> Hi Stefano and Emilio!
> 
> Emilio Pozuelo Monfort schreef:
>> Hello Stani!
>>
>> Stefano and I have been working on Spe to update it in Debian. 
> I have noticed and I am very thankfull! Don't hesitate to contact me for
> anything.
>> We are going to
>> maintain it in the Python Applications Packaging Team:
>> http://wiki.debian.org/Teams/PythonAppsPackagingTeam
> Great! I also recently joined that team. I prefer to focus on
> developping SPE and Phatch but want to give all my support for packaging
> and fixing things upstream where needed.
>>
>> While working on it, we have done some things which would be useful
>> for you to
>> have in the source tree. Having them on your side would also mean that
>> more
>> people would benefit from them.
> Nice!
>>
>> 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.

>>
>> There's also the problem with wxGlade, kiki, winpdb, pychecker... All
>> of those
>> modules are developed externally, and thus we believe it's a good idea
>> not to
>> have them included in the source tree, as that means there will be no
>> benefits
>> from bug fixes and improvements in those packages. So that's why are
>> removing
>> them (wxGlade, kiki and winpdb at this moment) from the binary
>> package, and
>> linking to those modules, which are available externally. This means less
>> maintenance work for us, and of course for you! So we would like to
>> have your
>> opinion on the matter. Would it be possible for you to remove them
>> from your
>> source tree? Specially wxGlade, which is big, but probably the rest too.
> I started developing SPE on Windows. As Windows doesn't have a nice
> packaging system as linux does, I included all of them as I wanted
> everything to run out of the box. Quite soon some linux users jumped
> into the spe source code and started to fix SPE for linux. Later the
> same happened for the Mac. Now I also use Linux and hardly touch
> Windows. However as spe users are cross-platform, the majority still
> uses Windows and I don't want to drop support for them. I know they
> prefer everything out of the box. As a linux user I agree that for linux
> it is better to strip them out of the release tarball. So for the sake
> of all spe users I will release two versions of spe: the normal one
> without plugins and one with all the extras.
> 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

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

>>
>> Also, we don't know what to do with pychecker. From
>> plugins/pychecker2/NOTES.txt
>> I see that pychecker2 is a rewrite of pychecker, but it doesn't seem
>> to be
>> available externally. I've found the original pychecker in the net,
>> and we have
>> it packaged in Debian, but I can't find any pychecker2. Did you
>> rewrite it
>> yourself? And, is Spe using pychecker2, pychecker, or both? I'd like
>> to get rid
>> of it too, but I'm not sure it's safe to do it and link to pychecker's
>> package
>> because of the rewrite. Any guidance on this would be more than
>> appreciate.
> pychecker and pychecker2 are standard packages of pychecker. They are
> not written by me. However I had to modify some lines of them as
> otherwise I was not able to make them interoperate with spe. This has
> been a while back. If you want, I can digg it up.

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

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?

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

Best,
Emilio

> 
>> That would help us a lot. And as minor request, renaming
>> spe_changes.txt to ChangeLog and using it would be nice (the last
>> entry is from
>> 0.7.4!) and possibly a README.
> Sounds good to me.
>>
>> I Look forward to hearing from you!
> As Stefano mailed me already before, I wanted to answer as quickly as
> possible. I will look more into the files you've sent.
> 
> Stani
> 
> PS. A bit off topic, you can skip this...
> Right now I am developing also a new application phatch (photo batch
> processor with a nice gui) http://photobatch.stani.be It lets you
> watermark, rotate, resize, apply rounded corners, shadows, ... thousands
> of photos with just one click. To write your own plugins you only need
> to know python & pil as phatch generates automatically all the user
> interface with international support
> https://translations.launchpad.net/phatch/trunk/+pots/phatch. I hope to
> get it in debian too. The structure of the source tarball as you will
> see is quite debian friendly.
> 

-------------- 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/2b6d3e94/attachment.pgp 