On Tue, Jun 7, 2016 at 11:14 AM, Nils Bruin <nbr...@sfu.ca> wrote:
> On Sunday, June 5, 2016 at 12:59:57 PM UTC-7, Nils Bruin wrote:
>>
>> The problem arose specifically when I was looking at
>> https://github.com/abelfunctions/abelfunctions which packages itself as an
>> spkg. Obviously, I didn't want to install this (when trying it out!) in a
>> system-wide sage, but I also didn't want to force the student who needed to
>> look at it to build a private sage version just to try out a package.
>>
> In fact, as it turns out, the spkg does contain relevant instructions in
> spkg-install. Running
>
> sage setup.py build_ext --inplace
>
> builds the extension without writing in any system directories. It doesn't
> seem to add anything to the search paths (and it probably shouldn't) so you
> have to add the relevant path to sys.path (or make sure that the current
> directory happens to be the relevant path). It's nice to see that extension
> modules produced by cython are picked up from those paths too.
The standard way to build in place but have things written to a search path is
python setup.py develop --user
Or to the system-wide search path (or whatever your python install is):
python setup.py develop
Building in place is similar to "python setup.py develop --user" but
adds nothing to any paths...
Here's another example of developing code for Sage in the same way as
the rest of the world uses Python:
https://github.com/williamstein/sage_modabvar
There's no Cython yet, but probably will be soon.
--
William (http://wstein.org)
--
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.
