Create shedskin package for laterly easier import/install about shedskin HOT 13 CLOSED

Forgot to add:

docstrings are missing to make it a 'perfect' package ;)

thanks! ;) I committed the patch, with a few small changes, and renamed ss.py to
__init__.py. please let me know if anything I changed seems wrong to you..

I moved bert.py to testdata/, since it's only used in the tests, and removed
backward.py, because it was only needed when using Python 2.3, which is not 
supported
anymore. thanks for noting! 

I really don't like to add .py to the 'shedskin' startup script, but I guess you
added this because it otherwise conflicts with the new 'shedskin' dir.. I'm now
thinking about writing a distutils setup.py, or would you be interested in 
adding that?

hm.. no time to investigate further, but the following now results in an error:

srepmub@akemi:~/shedskin/examples$ shedskin go
*** SHED SKIN Python-to-C++ Compiler 0.2 ***
Copyright 2005-2009 Mark Dufour; License GNU GPL version 3 (See LICENSE)

*ERROR* go.py:None: cannot locate module: builtin

(shedskin is a symlink in /usr/bin to shedskin.py)

Yeha, the patch from remove SHEDSKIN ROOT is wrong... :(

Here is another now correctly one ;)

Your changes are ok. I don't have yet much experience in creating packages. If 
you
believe this is the best method (moving ss.py into __init__.py...), it's ok ;)

Does extmod.py belongs in the shedskin package too? It should, but I'm not 
sure^^

Wouldn't it better to have just usage() and main() in __init__.py?

This patch moves generate_code to cpp.py (as suggested in TODO). What about 
analysis
and annotate?
I'd prefer to get it out of __init__ ;)

About annotation:
This is more useful for us, than for 'just' users of ss.
Second patch makes annotaion = False as std and shedskin -a or shedskin -ann 
enables
annotaion.

Ah, forgot to add in "now_properly_remove_SHEDSKIN_ROOT.patch":
in unit.py instead import ss[…] import shedskin[…]

thanks! I committed the new SHEDSKIN ROOT patch, but avoiding the 'shedskin' 
import
and magic constant of 22. let's find out what happens with this under windows 
later..

and you are right, I forgot to move extmod.py as well. 

will look at the other patches later today.

how about so? :)

you are right this is much better!

about annotation: I think this can also be useful for regular users, as it can
sometimes make it easier for them to understand some strange piece of code. but 
I
agree this is not typical usage, so the default should be 'off'. 

thanks for all the help!

You are welcome ;)

Hmm, how to install this later on? Where is lib with all .cpp and .hpp living?

With shedskin module installed in site-packages lib has to be there, too (with
current configuration).

So make it complicated and install them as header files in /usr/include or make 
it
simple and also move lib into the shedskin package. But what happens then 
inside of
the package? Means, then it's possible to call a "import shedskin.lib" or 
something
from outside?

I'm a bit confused atm :-D

I'm guessing distutils does this kind of thing in a standardized way.. maybe 
you'd
like to have a look at creating a distutils setup.py?

Could be, but how to determin the libdir from shared itself? If distutils 
installs it
where it wants to, we need to search at least at 2 places for the dir…

my guess is you can just ask distutils this?

If you wanted an easy distutils way of locating the bundled files, you could 
put the
lib directory inside the package and then specify it in the package_data 
parameter of
the distutils setup function in the setup.py script. Then, after installation, 
the
lib directory would reside inside shedskin in site-packages and you could 
generate
the necessary -I flags dynamically (for the Makefile) by asking for the lib
subdirectory of shedskin.__file__.

I'm not sure how compatible this is with Debian guidelines, for example, but I 
do
similar things with some of my own packages. Generally, distutils is quite 
deficient
in dealing with the wider filesystem, but this is the least worst solution.