On Dec 23, 4:07 am, Martin Albrecht <m...@informatik.uni-bremen.de> wrote:
Hi, > Despite the concrete criticism of Michael I want to point out that I very much > like the spirit of what you're doing here! Yes, Georg is trying to solve a problem complex that needs to be solved, I just think he is going about it the wrong way. Having thought about this and having taking another look I would suggest to do the following: We are having to solve three problems with overlap (a) How to build a C library and install it into SAGE_LOCAL (b) How to build Cython bindings (c) How to do integrate code depending on Sage in a clean way and install it into site-packages (a) is pretty much covered by the example spkg-install at http://wiki.sagemath.org/SPKG_Audit and I think that is the way to do it. The example is missing some bits about how to apply patches, i.e. copy over modified files, and that one should attempt to delete old versions of the library as well as headers. For (b) it depends if those Cython bindings are Sage specific or are generic Python bindings. If it is Sage specific I would deal with them via (c), if not they can be part of the library.spkg and be build and installed once the library has been build and installed. (c) is the tricky bit. There are various approaches: * the old Sage Words library approach, i.e. before it become part of Sage-combinat and was recently merged. Back then the Words install process monkey-patched setup.py which was error prone and sooner or later would have ceased working, i.e we introduced module_list.py. Having an external project that attempts to replace functionality in the Sage library is a big no IMHO and fortunately this has been resolved by upstreaming the code in this specific instance. This was intended for some time and I am not aware of any other external Sage library that wants to patch itself into Sage and does not plan to upstream itself. I.e. sage-combinat is not a problem case here since the plan is for all the code to be upstreamed as it matures and becomes ready. * the stand alone approach in site-packages: Nobody does this yet, but I think it is only a question of time. This would not cover pure Python code, but code that depends on the Sage library. The ideal solution IMHO here is to use distutils and so on and treat the code just like any other python based spkg, i.e. in spkg-install * check the the Sage env is declated or error out * nuke the old install in site-packages or error out * python setup.py install or error out Technically the following is more elegant, but we don't do it yet: * check the the Sage env is declated or error out * python setup.py build or error out * nuke the old install in site-packages or error out * python setup.py install or error out That way a failed build does not render that Python package non- functional. The above introduces a clean separation between external Sage libraries and the core. We could certainly introduce infrastructure so that those libraries could register themselves as external packages for example. I would also very much lobby for separating C library spkg and non- core library Sage binding since Sage now offers infrastructure to check for installed spkgs and even install them on demand. Separating functionality is the clean way to go unlike certain spkgs like R (which includes rpy) or PolyBori (which ships its own copy of a boost subset) since those spkgs are harder to upgrade and more things can go wrong. I.e. there are OS combos where R builds just fine, but rpy blows up. In the end if you come up with useful generic infrastructure that should go into the Sage scripts repo or in some cases into the Sage library. For example I planto clean up all the uname handling for various OSes and stick them in there since I have to reproduce code snippets all over the various spkgs and having it all in one place is just cleaner and easier to maintain. > Cheers, > Martin Cheers, Michael > -- > name: Martin Albrecht > _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 > _www:http://www.informatik.uni-bremen.de/~malb > _jab: martinralbre...@jabber.ccc.de --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
