On Tue, Jun 7, 2016 at 12:04 PM, Nathan Dunfield wrote:
>> While this might work for simple projects, this won't work when you need
>> the metadata that cythonize() adds. For example, anything using
>> cysignals really must use cythonize(), it won't work otherwise.
>
>
> Jeroen,
>
> As of Cython 0
On 2016-06-07 18:04, Nathan Dunfield wrote:
Specifically, if you look at the top of a Cython-generated C file, there
is what looks to be a JSON string encoding the metadata.
Right, although I don't know if this is used by anything. In any case,
this might still not be enough since the metadata
On Sun, Jun 05, 2016 at 11:25:01PM -0400, William Stein wrote:
> We had tons of discussion on sage-devel about exactly this topic
> recently. One thing is that Chris made
>
> https://github.com/cswiercz/sage_packages
>
> but that seems to have gone nowhere.
There is also this wiki page that we
>
> While this might work for simple projects, this won't work when you need
> the metadata that cythonize() adds. For example, anything using
> cysignals really must use cythonize(), it won't work otherwise.
>
Jeroen,
As of Cython 0.22, it looks like the metadata you refer to is cached in th
On 2016-06-07 17:20, William Stein wrote:
I was going to post that my understanding is that shipping
Cython-generated files is the current standard way of shipping Cython
code (for better or worse).
While this might work for simple projects, this won't work when you need
the metadata that cyth
>
> > Agreed, it's certainly what the Cython docs recommend:
> >
> >
> http://docs.cython.org/src/reference/compilation.html#distributing-cython-modules
>
>
> Ah, okay. I didn't see that before. At least it's the recommended
> best practice. It should be easier to do automatically though
On Tue, Jun 7, 2016 at 11:27 AM, Nathan Dunfield wrote:
>> > Interesting, I didn't realize that build-time (as opposed to run-time)
>> > dependencies were even *possible* with setuptools, even if it does
>> > require a
>> > hack. With SnapPy, we just ship the Cython-generated C/C++-files in the
>
On Tue, Jun 7, 2016 at 11:20 AM, William Stein wrote:
> On Tue, Jun 7, 2016 at 11:18 AM, Nathan Dunfield wrote:
>> Erik,
>>
>> Interesting, I didn't realize that build-time (as opposed to run-time)
>> dependencies were even *possible* with setuptools, even if it does require a
>> hack. With Snap
>
> > Interesting, I didn't realize that build-time (as opposed to run-time)
> > dependencies were even *possible* with setuptools, even if it does
> require a
> > hack. With SnapPy, we just ship the Cython-generated C/C++-files in the
> > tarball that we post on PyPI.
>
> I was going to pos
Erik,
Interesting, I didn't realize that build-time (as opposed to run-time)
dependencies were even *possible* with setuptools, even if it does require
a hack. With SnapPy, we just ship the Cython-generated C/C++-files in the
tarball that we post on PyPI. It adds a bit to the tarball's size,
On Tue, Jun 7, 2016 at 11:18 AM, Nathan Dunfield wrote:
> Erik,
>
> Interesting, I didn't realize that build-time (as opposed to run-time)
> dependencies were even *possible* with setuptools, even if it does require a
> hack. With SnapPy, we just ship the Cython-generated C/C++-files in the
> tar
On Tue, Jun 7, 2016 at 9:53 AM, Erik Bray wrote:
> On Mon, Jun 6, 2016 at 5:01 PM, Jeroen Demeyer wrote:
>> On 2016-06-06 16:05, William Stein wrote:
>>>
>>> Isn't there one canonical one to use now?
>>
>>
>> I guess the "canonical" one is setuptools. But setuptools makes the annoying
>> assumpti
On Tue, Jun 7, 2016 at 10:59 AM, Jeroen Demeyer wrote:
> On 2016-06-07 10:57, Erik Bray wrote:
>>
>> Yes, but it's a pain in the butt to do and would require support from
>> the setuptools end
>
>
> I must be missing something... setuptools allows declaring dependencies,
> right?
Yes but again th
On 2016-06-07 10:57, Erik Bray wrote:
Yes, but it's a pain in the butt to do and would require support from
the setuptools end
I must be missing something... setuptools allows declaring dependencies,
right?
--
You received this message because you are subscribed to the Google Groups
"sage-d
On Tue, Jun 7, 2016 at 10:36 AM, Jeroen Demeyer wrote:
> On 2016-06-07 10:21, Erik Bray wrote:
>>
>> It's one thing to depend on a package at runtime. It's another thing
>> to have a dependency just so that `./setup.py --help` can work without
>> raising an ImportError :)
>
>
> Well, could it be
On 2016-06-07 10:21, Erik Bray wrote:
It's one thing to depend on a package at runtime. It's another thing
to have a dependency just so that `./setup.py --help` can work without
raising an ImportError :)
Well, could it be possible to arrange things such that Cython is needed
at *build-time* b
On 2016-06-07 10:19, Francois Bissey wrote:
It does exactly what it should. “—root” is the equivalent of DESTDIR for
autotooled packages. It is meant for use by distribution to install in a staging
area.
No, really not! I think that --root/DESTDIR should only change the
absolute installation p
On Tue, Jun 7, 2016 at 10:17 AM, Jeroen Demeyer wrote:
> On 2016-06-07 09:56, Erik Bray wrote:
>>
>> This should probably be fixed. Do you know if there has been any
>> discussion about this or just a lack of maintenance?
>
>
> No idea.
>
>>> I don't mind assuming that Cython is installed. It mak
On Tue, Jun 7, 2016 at 10:14 AM, Jeroen Demeyer wrote:
> On 2016-06-07 09:53, Erik Bray wrote:
>>
>> $ ./setup.py install --root=root
>
>
> Well, it seems that setuptools behaves completely differently if --root is
> set, no idea why...
I explained this is because --root implicitly disables easy_
> On 7/06/2016, at 20:14, Jeroen Demeyer wrote:
>
> On 2016-06-07 09:53, Erik Bray wrote:
>> $ ./setup.py install --root=root
>
> Well, it seems that setuptools behaves completely differently if --root is
> set, no idea why...
>
> With --root=/tmp
>
> [...]
> copying banshees.txt -> /tmp/usr
On 2016-06-07 09:56, Erik Bray wrote:
This should probably be fixed. Do you know if there has been any
discussion about this or just a lack of maintenance?
No idea.
I don't mind assuming that Cython is installed. It makes things a lot
simpler.
Users will mind, I guarantee it
There are ma
On 2016-06-07 09:53, Erik Bray wrote:
$ ./setup.py install --root=root
Well, it seems that setuptools behaves completely differently if --root
is set, no idea why...
With --root=/tmp
[...]
copying banshees.txt -> /tmp/usr/local/src/sage-git/local/shared/siouxsie
[...]
Without --root
[...]
On Tue, Jun 7, 2016 at 9:24 AM, Jeroen Demeyer wrote:
> On 2016-06-07 08:55, Erik Bray wrote:
>>
>> In fact Cython used
>> to advertise a CythonBuildExt command (i forget of that's exactly the
>> name) that overrides the default build_ext command to also compile
>> Cython modules as needed.
>
>
>
On Mon, Jun 6, 2016 at 5:01 PM, Jeroen Demeyer wrote:
> On 2016-06-06 16:05, William Stein wrote:
>>
>> Isn't there one canonical one to use now?
>
>
> I guess the "canonical" one is setuptools. But setuptools makes the annoying
> assumption that a Python package is completely self-contained and t
On 2016-06-07 08:55, Erik Bray wrote:
In fact Cython used
to advertise a CythonBuildExt command (i forget of that's exactly the
name) that overrides the default build_ext command to also compile
Cython modules as needed.
This still exists in the Cython package, but they no longer document it.
On Mon, Jun 6, 2016 at 5:25 AM, William Stein wrote:
> We had tons of discussion on sage-devel about exactly this topic
> recently. One thing is that Chris made
>
> https://github.com/cswiercz/sage_packages
>
> but that seems to have gone nowhere.
>
> I think that **all** development of Sage sho
On 2016-06-06 17:06, William Stein wrote:
And yet you can do anything you want in setup.py... It's not hard to
get around that.q
First of all, those hacks will most likely break setup.py in one way or
another. For example, they might break wheel or "setup.py dist" or whatever.
Second, why sh
On Mon, Jun 6, 2016 at 11:01 AM, Jeroen Demeyer wrote:
> On 2016-06-06 16:05, William Stein wrote:
>>
>> Isn't there one canonical one to use now?
>
>
> I guess the "canonical" one is setuptools. But setuptools makes the annoying
> assumption that a Python package is completely self-contained and
On 2016-06-06 16:05, William Stein wrote:
Isn't there one canonical one to use now?
I guess the "canonical" one is setuptools. But setuptools makes the
annoying assumption that a Python package is completely self-contained
and that no other software ever needs to use files from that Python
p
On Monday, June 6, 2016, Jeroen Demeyer wrote:
> On 2016-06-06 05:25, William Stein wrote:
>
>> I think that **all** development of Sage should be done using standard
>> Python packaging.Of course Cython is very well supported using
>> setuptools
>>
>
> or distutils if you prefer that.
Isn'
On 2016-06-06 05:25, William Stein wrote:
I think that **all** development of Sage should be done using standard
Python packaging.Of course Cython is very well supported using
setuptools
or distutils if you prefer that.
--
You received this message because you are subscribed to the Google
We had tons of discussion on sage-devel about exactly this topic
recently. One thing is that Chris made
https://github.com/cswiercz/sage_packages
but that seems to have gone nowhere.
I think that **all** development of Sage should be done using standard
Python packaging.Of course Cython is
If one is experimenting with mathematical computations, one would usually
start interactively, with a jupyter worksheet, an emacs buffer, or just a
terminal with cut&paste. The sage environment is pretty good for that. Once
the project gets larger, one would start to put code into files that are
33 matches
Mail list logo
