<br><br><div class="gmail_quote">On Mon, Nov 1, 2010 at 10:18 PM, Bernhard Herzog <span dir="ltr"><<a href="mailto:bh@intevation.de" target="_blank">bh@intevation.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 29.09.2010, Igor Novikov wrote:<br>
> Distutils build supposes that installed python application/library contains<br>
> one or several<br>
> python packages.<br>
<br>
</div>That could be worked around, if necessary.</blockquote><div><br>I prefer avoiding abundant workarounds because <span lang="en"><span title="">enough of the problems <br>that already exist in various</span></span> Linux distributions.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> One general problem applications<br>
like Skencil have with distutils is that distutils is meant for libraries,<br>
not applications.<br></blockquote><div><br>It seems this conclusion is not correct. Distutils is meant for module distribution,<br>not libraries only.<br><br><a href="http://docs.python.org/distutils/introduction.html" target="_blank">http://docs.python.org/distutils/introduction.html</a><br>
<br>There is a lot of python end user application which use distutils without workarounds, <br>just for conventional install.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
> Therefore internal Skencil structure was wrapped as a single package with<br>
> unique 'skencil' name.<br>
<br>
</div>It doesn't have to be a package. That's what I'm concerned about and it's what<br>
I think is wrong, currently. What exactly is your goal? </blockquote><div><br>The primary goal is provide a lot of packages for different latest distros. And these packages<br>should be really working packages but not a fake without dependencies. <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">If the goal is to<br>
make it possible for someone to install Skencil and then to be able to write<br>
python code that can import Skencil modules without any additional PYTHONPATH<br>
or sys.path modifications, that could have been achieved without an<br>
additional package. It would have sufficed to put a single python module,<br>
called e.g. skencil.py, into site-packages that when imported adds the actual<br>
installation directory of Skencil to sys.path. Where Skencil is actually<br>
installed doesn't really matter in that case. It could still be in a<br>
sub-directory of site-packages if that's not a python package.<br>
<br>
That's an approach we used in Thuban. Its setup.py creates a file<br>
thubaninit.py in site-packages with basically just the following content:<br>
<br>
sys.path.insert(0, %(thubandir)s)<br>
<br>
<br>
Where %(thubandir)s is replaced with the actual installation directory.<br>
See e.g.<br>
<a href="https://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/thuban/setup.py?rev=2889&root=thuban&view=markup" target="_blank">https://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/thuban/setup.py?rev=2889&root=thuban&view=markup</a><br>
for how that's put into setup.py.<br></blockquote><div><br>Extra complex setup.py is great for programmers, not for regular users.<br>There is no difference in runtime where application is installed. But <br>Thuban compilation is a rocket science for conventional user. Whereas <br>
Skencil 1.0alpha package can be built by simple command:<br><br><div style="margin-left: 40px;">python setup.py bdist_rpm<br></div><br>or for Debian distros:<br><br><div style="margin-left: 40px;">python setup.py bdist_deb<br>
</div><br>Any user prefers installing package but Thuban setup.py doesn't provide<br>such possibility. So people need waiting for application update in repository.<br>Sometime it takes more than one year. Also you cannot providing ready<br>
packages for latest release <span id="result_box" class="short_text" lang="en"><span style="" title="">because such task takes a lot of time</span></span>.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I think the extra skencil package should be removed again before the final<br>
release.<br>
<div><br>
> Of course all these folders could be moved inside Sketch package but this<br>
> will lead to serious<br>
> project refactoring. Also when you import Sketch package __init__.py runs a<br>
> lot of initializing code<br>
> including some tricks like creating runtime packages. Such behavior breaks<br>
> a work of some<br>
> python applications.<br>
<br>
</div>In what way to they break?<font color="#888888"><br></font></blockquote><div><br>Initially UniConvertor had a structure as you proposed, i.e. root package __init__.py<br>was similar to Sketch __init__.py But after RH bugreport we have fixed this issue:<br>
<br><a href="https://bugzilla.redhat.com/show_bug.cgi?id=484301">https://bugzilla.redhat.com/show_bug.cgi?id=484301</a><br></div></div><br>I think it's not a good idea reproducing this issue in Skencil. Root package should not<br>
contain a heavyweight initialization. Currently Sketch package serves as a global reference<br>for different components. This is really bad pattern like global variables in Basic/PHP<br><br>So my personal opinion is:<br><br>
1.Don't change project structure for 1.0 (Tk version). Actually it's almost the same <br> Skencil 0.6.17 structure. Take a look on following illustration:<br><br><a href="http://saveimg.ru/pictures/02-11-10/6facaf814684b114a74fb3b84a9e94f2.png">http://saveimg.ru/pictures/02-11-10/6facaf814684b114a74fb3b84a9e94f2.png</a><br>
<br> Only startup script is replaced by __init__.py and Lib/ package is removed.<br> But as a result we have simple and efficient package build. I think revitalizing<br> milestone is not for deep project refactoring. <br>
<br>2.Developing next Gtk version resolve this issue removing all tricks from application <br> start (runtime Base package, Sketch package as a global reference etc.)<br><br clear="all"><br>-- <br>Regards,<br><br>Igor Novikov<br>
sK1 Project<br><a href="http://sk1project.org" target="_blank">http://sk1project.org</a><br><br><br>