[Skencil-devel] Revitalising Skencil

[Bernhard Herzog]

Igor Novikov <igor.e.novikov at gmail.com> writes:

> On Sun, Nov 7, 2010 at 10:01 PM, Bernhard Herzog <bh at intevation.de> wrote:
>> I originally thought that now it would be possible to easily import Skencil
>> from a program that wanted to use it as a library.  It turns out that that
>> is, in fact, not possible, because the path manipulation is necessary and
>> only done in skencil_run which also starts the application. So, given the
>> current implementation, there does seem to be no reason at all for the code
>> to be installed in Python's site-packages directory.
[...]
> All changes in project structure (exactly moving project code into
> site-packages/)

Actually, installing in site-packages is not what I don't like, per se,
it's the extra skencil package, and in particular, that it's a package
and not just a directory.  Installing in site-package does imply that
it's a library for general use by other Python programs, because
otherwise there's no real point in putting the code there.  So I assumed
that that might have been one goal for that change.  I was mistaken.

So the site-package part of the issue boils down to: If it's usable as a
library, it's fine to install in site-packages.  However, currently it's
not so there's no point in installing it there, and in fact it might be
confusing for Python programmers.

It's actually quite easy, to make it work as a library.  Just make sure
that you can import Sketch without running the application.

> have one common goal: to simplify project distribution
> and packaging (packaging is equivalent for distribution through
> repositories). Packagers are not Python programmers but rather
> advanced Linux users. So complex build inhibits project packaging.

I'm not sure why you think I propose to make packaging more difficult.
All a packager has to do, is run "python setup.py build" and "python
setup.py install" and put all files installed by that into the package.
Or, they could use the existing bdist_* commands, if they do what the
packagers need.  That won't change.  Skencil's setup.py might be a
little more complex, but the packagers shouldn't have to care about
that.

If packagers do want to do something different that how Skencil is
installed by default, they better be reasonably experienced Python
developers, because regardless of how simple the setup.py script is,
they better know what they're doing.

> All my fixes in Skencil code are point fixes just to eliminate
> existing issues & bugs (excepting code reformatting because this
> procedure is a technical manipulation).  There is no sense on this
> milestone to develop such advanced features like subpackages for
> external use.

And that's not something I'm actually proposing.  It's just that one
consequence of your changes is that Skencil is now installed in
site-packages, which normally implies that its a library for general use
by Python programs.  So I assumed that that might have been one goal for
that change.  That's all.

> So on first milestone we just announce a project rebirth but on next
> step we should selecting a correct strategy for further project
> development.

Indeed.  Let's get 1.0 first and then talk about the future after that.
There's enough to do still for 1.0.

Regards,

  Bernhard