On 15/04/16 16:48, John H Palmieri wrote:
On Friday, April 15, 2016 at 11:04:37 AM UTC-7, mmarco wrote:
El viernes, 15 de abril de 2016, 19:35:00 (UTC+2), vdelecroix escribió:
On 15/04/16 14:18, mmarco wrote:
I would consider graphs to be part of the core. There are many other
modules that deppend on it. Maybe it could be split in two parts
though.
I still consider that where to split should not be part of the current
discussion.
I think one of the problems to be addressed is that we lack a system to
have "external packages". We do have "optional packages", but that is
another history, since they go through the usual development process.
One
has to write the corresponding scripts, open an account in trac, open a
ticket, and wait for it to be reviewed, this stops a lot of people. We
would need something simpler for people that just wrote a few functions
to
compute something related to their research, and want to share them
with
others.
+1. The need of modifying Sage source code to have an external package
is very bad. Moreover, it does not give any guarantee that a given
optional package is actually working (beyond the fact that some people
actually uses it). So this is about:
* how to completely externalize existence of optional packages (Python
packaging/library is one way already in use)
* how to integrate in the patchbot testing optional packages (see
#20182 in that direction)
But on the other hand, if Sage core has no idea about the list of
packages, how could we test them? Would make sense to have somewhere a
list of packages together with a classification along:
- link to tarball broken
- does not build
- does build but have not test suite or test suite fails
- does build and test suite succeeded
The current optional vs experimental reflects this a bit.
My proposal would go in the direction of having three categories:
optional, experimental, and external. Optional and Experimental would
follow moreless what we have now, external programs that provide some
functionality, and we keep them in our packaging system because we cannot
rely on them being provided by the distro (or maybe we could, but we need
some patching or specific version). They are more tied to "Sage the
distribution" than to "Sage the library".
What I propose to call external packages would be something different.
They would go in the spirit of sage/python code writen by sage users for
their teaching/rsearch/whatever. In that sense, they would be in spirit
closer to "Sage the library", but the Sage development team would make no
promises about it (since it wouldn't go through the review process). They
could be provided by any of the usual ways to install python modules (pip,
easy_install...) but we could have some kind of database to do some
automatic testing. We could even distribute them (as optional packages or
calling them dfifferently). I think providing a template and howto for the
people that wants to share this kind of code is a good start. A next step
would be to maintain a database and maybe include some automated way to
install them.
Would it also be possible for them to be installed either in the main Sage
directory or in the user's .sage directory, depending on how the
installation was invoked and/or permissions? Pardon my ignorance, but how
does Python deal with this?
It is not only about Python but operating system distribution. Usually
on linux everything is managed by the distribution and you just have to
do "apt-get install python-nice-package" (or yum or whatever). This
results in a global installation usually in /usr/lib/pythonversion/.
Should be similar under FreeBSD. Though this needs the intervention of
some administrator.
You can also do this "out of the distro" using "pip".
If you want to add user packages you need to setup environment variables
PYTONPATH and/or PYTHONHOME [1] pointing to the appropriate directory.
Otherwise your python would not be able to find your libraries. To
install a module that way with pip
$ pip install -t DIR package
Concrete example
$ pip install -t /home/john/lib/ biopython
$ export PYTHONPATH=/home/john/lib/
$ python
and then biopython is available!
There is also the alternative possibility of having virtual environment
for even more isolation [2].
I am sure that there are more ways of doing things some of which I do
not know of.
Vincent
[1] https://docs.python.org/3.4/using/cmdline.html
[2] http://docs.python-guide.org/en/latest/dev/virtualenvs/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
