Support compiling of local unknown python modules

[GoogleCodeExporter]

If shedskin currently does not support an unknown python module, it exits
with "module not found".

With this patch, it tries to copy the module in a subdir "genmod" and tries
to compile it there. After that we can add this directory in the Makefile
so the programm can fetch the new module.cpp/.hpp from there.

The reason for generating "genmod" and not copy it to the lib dir is, that
anything from lib dir should be maintained and shipped by shedskin. But on
an installed system any other user should not be allowed to modify/add
files in this folder. Therefore this patch keeps anything in the local
folder in "genmod" (another better name proposal is welcomed^^).

Original issue reported on code.google.com by thomas.s...@gmail.com on 23 Aug 2009 at 5:20

Attachments:

• 0001-Support-genmod-directory-where-shedskin-get-called.patch

[GoogleCodeExporter]

(as discussed per mail:)

this is an interesting thought/patch, and I will try to think about it
more, but for now I'm hesitant to include something like this..

an important reason is that to me it's often a good idea to not
support something until it works well, and generate a clear error
message before then, so the end user has a clear idea what is wrong
and possibly can work around it him/herself.

with this patch, the end result will usually still be failure, but now
with more cryptic error output. and if it typically doesn't lead to
failure for some module, why not just add the module to the shedskin
lib/ dir..?

another reason is that type inference is typically much more difficult
on a full program than on a simplified type model (lib/*.py)..

Original comment by mark.duf...@gmail.com on 24 Aug 2009 at 3:51

• Changed state: WontFix

[GoogleCodeExporter]

"an important reason is that to me it's often a good idea to not
support something until it works well"

-> I created this issue here for others to be able to test it and further 
improve it.
If it's closed as WontFix this doesn't help a bit. If you would let it open, 
anyone
who is interessted in this project will check it out and maybe start working on 
it.
WontFix is for something considered as nonesence and throwing away…

"with this patch, the end result will usually still be failure, but now
with more cryptic error output"

-> Mostly it will failure, but with a nice error output, easy to understand:
Leaving copyright notice out and running: "shedskin cpp.py"

Trying to compile module textwrap into c++

*ERROR* textwrap.py:77: unicode is not supported
*ERROR* cpp.py:13: module textwrap could not compiled to c++

in cpp.py is "import textwrap" -> SS tries to compile module textwrap as 
displayed on
console. -> This is failing, because unicode is not supported -> That's why cpp 
fails
(textwrap coult not compiled).
Not cryptic at all.

"why not just add the module to the shedskin lib/ dir..?"

->(As mentioned in comment 0.): 
Reported by toms...@fedoraproject.org, Aug 23 (2 days ago)

If shedskin currently does not support an unknown python module, it exits
with "module not found".

With this patch, it tries to copy the module in a subdir "genmod" and tries
to compile it there. After that we can add this directory in the Makefile
so the programm can fetch the new module.cpp/.hpp from there.

The reason for generating "genmod" and not copy it to the lib dir is, that
anything from lib dir should be maintained and shipped by shedskin. But on
an installed system any other user should not be allowed to modify/add
files in this folder. Therefore this patch keeps anything in the local
folder in "genmod".

Original comment by thomas.s...@gmail.com on 25 Aug 2009 at 11:09

[GoogleCodeExporter]

I changed the status to 'new'. will reply to the rest later..

Original comment by mark.duf...@gmail.com on 26 Aug 2009 at 8:52

• Changed state: New

[GoogleCodeExporter]

>Not cryptic at all.

shedskin may not even finish if the library is large, because of type inference 
not
completing. or if it encounters some unsupported construct, we'd much rather 
like to
just tell the user that the module is not supported, rather than 'warning: 
system
keyboard interrupt is not caught' or similar.. :) also if it compiles you don't 
want
to let the user test if it really works. imo, it's much better to not support 
some
unknown library until it actually compiles, it is tested, and there is a 
smallish
type model that makes compilation of programs that use them (much) easier.. 

Original comment by mark.duf...@gmail.com on 28 Aug 2009 at 3:18

[GoogleCodeExporter]

Original comment by mark.duf...@gmail.com on 18 Mar 2010 at 7:55

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I merged all standard library issues into issue 106.

Original comment by mark.duf...@gmail.com on 27 Oct 2010 at 1:01

• Changed state: Duplicate