Opened 12 years ago

Closed 8 years ago

#6415 closed enhancement (wontfix)

"sage -t foo.pyx" should not by default dynamically build foo.so

Reported by: GeorgSWeber Owned by: GeorgSWeber
Priority: minor Milestone: sage-duplicate/invalid/wontfix
Component: doctest framework Keywords:
Cc: Merged in:
Authors: Reviewers: David Roe
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

Recently (during Sage Days 12 ?!) the doctesting code was changed so that "sage -t" on a certain class of *.pyx files now is broken. Especially, they now get not only copied to some temp directory, but it is attempted to build dynamically the *.so extension out of them, as if they were all files to be loaded/attached. This almost certainly must fail, if e.g. you have installed a package under $SAGE_ROOT/local/lib/python/site-packages/, with Cython extensions, building which needs certain libraries, additional C sources, special compiler flags, and so on. (And where one "imports" the functionality, not loads/attaches it.)

Previously, doctesting was very well suited to this situation, but is no more.

So the current (Sage 4.0.2) doctesting code should be enhanced in e.g. one of the following ways:

1) If "dynamically building" of an extension fails, just "try" to import the functionality as a fallback (in other words: use a prebuilt *.so if one exists, and you can't build a fresh one)

2) Change to the old behaviour, and additionally try build dynamically an extension only if it is missing and/or seems to be outdated compared to the *.pyx file

3) Use the old/new behaviour depending on whether ".../site-packages/..." is in the path of the *.pyx-file, or not.

At the core of these problems of course is the fact that there is no standard way to store the build information (not to talk of the "full" dependency information) for a Cython source file. The Sage project e.g. invented its own custom-made monolithic "module_list.py" on the one hand, its custom-made #clib, #cinclude, ... pragmas on the other hand, but all this does not at all work smoothly together. Let alone being usable in Sage-related Cython projects which address a broader audience, and are thus placed under .../site-packages/.

Change History (7)

comment:1 Changed 10 years ago by Stefan

  • Report Upstream set to N/A

I ran into this today, but it seems that the -force_lib option solves the issue (it did for me, at least). Am I right?

comment:2 Changed 10 years ago by GeorgSWeber

  • Milestone changed from sage-4.7 to sage-wishlist
  • Owner changed from tbd to GeorgSWeber
  • Priority changed from major to minor
  • Type changed from defect to enhancement

Hi Stefan, good catch! Yes, I do think the issue of this ticket currently is solvable this way, i.e. alternative 1) of the description is actually (May 2011) implemented halfways.

(No automatism yet, but there's this additional command-line option to forcefully use already existing prebuilt "Python extension" .so-files).

If this ticket bit-rots another two years, it should be closed as "Won't Fix".

Cheers, Georg

comment:3 Changed 8 years ago by roed

Well, it's been almost another two years. ;-)

What's the status of this ticket after #12415? Are the problems still present?

comment:4 Changed 8 years ago by roed

  • Component changed from doctest to doctest framework

comment:5 Changed 8 years ago by roed

  • Status changed from new to needs_review

comment:6 Changed 8 years ago by roed

  • Milestone changed from sage-wishlist to sage-duplicate/invalid/wontfix
  • Reviewers set to David Roe
  • Status changed from needs_review to positive_review

sage -t foo.pyx building the module is a feature not a bug.

comment:7 Changed 8 years ago by jdemeyer

  • Resolution set to wontfix
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.