On 9 April 2013 14:55, Nikita Nemkin <nik...@nemkin.ru> wrote: > On Tue, 09 Apr 2013 19:33:20 +0600, mark florisson < > markflorisso...@gmail.com> wrote: > >> On 9 April 2013 14:24, Stefan Behnel <stefan...@behnel.de> wrote: >> >> mark florisson, 09.04.2013 15:13: >>> > On 9 April 2013 14:11, Stefan Behnel wrote: >>> >> Nathaniel Smith, 09.04.2013 15:00: >>> >>> On 9 Apr 2013 13:50, "Stefan Behnel" wrote: >>> >>>> There's also the problem of dependency hell and getting rid of old >>> >>>> modules >>> >>>> once they are no longer used on the user side. And also, how to get >>> them >>> >>>> there in the first place. Having one package overwrite the files of >>> >>>> another during its installation is just asking for trouble. >>> >>> >>> >>> The system I described does not involve the addition of any new files >>> to >>> >>> any package. >>> >> >>> >> I take it then that you were envisaging a separate "cython-runtime" >>> package >>> >> on PyPI that Cython compiled modules would have to depend on? >>> >> >>> >> As long as people install their stuff using pip, that could work for >>> them >>> >> mostly ok, although with the regrettable Cython user impact of having >>> to >>> >> set that dependency for their packages in the first place. >>> >> >>> >> If people want to install stuff manually, dependency hell gets close. >>> >> >>> >> Or did you see any other ways of getting these things installed >>> >> automatically, with a smaller user impact? >>> > >>> > For reference, here's a CEP about this written last year: >>> > http://wiki.cython.org/**enhancements/libcython<http://wiki.cython.org/enhancements/libcython> >>> >>> Ok, but that CEP excludes the rather vital problem of distribution and >>> installation. I also fail to see a reference to the problem of how >>> multiple >>> modules will interact that use different Cython runtime versions. That's >>> a >>> substantially bigger problem once symbols start becoming externally >>> visible. >>> >>> Stefan >>> >>> ______________________________**_________________ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/**mailman/listinfo/cython-devel<http://mail.python.org/mailman/listinfo/cython-devel> >>> >>> >> I didn't say it was complete :) But the way I see it is basically what >> Nathaniel said, i.e. Cython modules dependent on the runtime import it at >> import time. It simply imports 'cython.runtime<xxx>', which has been made >> available by the first module to initialize the runtime (compiled with >> --include-runtime), or otherwise must be present on the filesystem. So >> user >> packages can depend on a cython-runtime-x.y package (where each x.y is a >> different package), so pip will install all the runtime versions users >> need >> (or maybe we can otherwise improve upon this scheme). >> > > Extra dependency may not matter much for scientific code, > but there are other users of Cython: library bindings, speedups > for general purpose modules etc. Another (versioned!) binary dependency > will become a liability to them. >
Which is why it's optional: include the runtime separately, in a single module, or in every module. > If memoryviews rely on autogenerated (module-specific) code, > how is common runtime supposed to help? > The bulk of Cython utility code is also either inline or module-specific. > A fair amount is, though there is certainly room for externalizing (in the form of a runtime library as well as a header file). And as mentioned, it'd be useful to share Cython extension classes that cython inserts in each module. And sure, a header file is really arguing over a few bytes on disk and over the network. But it really does make it easier to inspect generated C code. > One alternative for code reuse in large Cython projects > could be packaging multiple modules into one shared library. > We have 'include'! :) Seriously though, that wouldn't work well with the import mechanism, and probably not for C compile time either. > > Best regards, > Nikita Nemkin > > ______________________________**_________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/**mailman/listinfo/cython-devel<http://mail.python.org/mailman/listinfo/cython-devel> >
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
