Ticket #4797 (closed defect: worksforme)
Run sage -ba instead of sage -b after upgrading Cython
| Reported by: | mabshoff | Owned by: | mabshoff |
|---|---|---|---|
| Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
| Component: | build | Keywords: | upgrade cython |
| Cc: | robertwb | Work issues: | |
| Report Upstream: | N/A | Reviewers: | Jeroen Demeyer |
| Authors: | Merged in: | ||
| Dependencies: | Stopgaps: |
Description (last modified by jdemeyer) (diff)
We should really run sage -ba when we upgrade Cython and not just sage -b.
Change History
comment:1 Changed 4 years ago by mabshoff
- Description modified (diff)
- Milestone changed from sage-3.4 to sage-3.2.2
comment:3 Changed 4 years ago by mabshoff
I can live with this issue being fixed in 3.3 since we will not upgrade Cython in 3.2.2->3.2.3.
Cheers,
Michael
comment:4 Changed 4 years ago by mabshoff
- Milestone changed from sage-3.2.3 to sage-3.4
Ooops. Reassigned this time :)
Cheers,
Michael
comment:5 Changed 4 years ago by was
Does anybody have any idea how to implement this? Here is one idea. We make it so there is a command like "sage -ba" that doesn't actually rebuild the sage library, then we make the cython spkg-install call that command. It could be called "sage -ba_nobuild" or something. This is way better, I think, than "sage -ba" trying to detect if cython was upgraded.
The disadvantage is that it might make testing installing the cython SPKG inconvenient.
comment:6 Changed 4 years ago by robertwb
Yes, this would make testing Cython spkgs a major pain. I think this probably best belongs in the upgrade script--it could touch all .pyx files after upgrading the Cython script.
comment:7 Changed 4 years ago by mabshoff
Yes and no. When I test Cython releases I delete the build tree and then do a -ba anyway since that is the only reliable way to test. Obviously if someone is testing "just" the spkg this ought to be not enforced, so RobertWB's idea seems the way to go.
Cheers,
Michael
comment:8 Changed 4 years ago by robertwb
Yep, when you test a Cython release (assuming I've done my job) it should just work. That's different when I'm hunting down a bug and want to keep re-compiling a certain file (e.g. that last memory leak).
comment:9 Changed 4 years ago by was
- Priority changed from blocker to critical
If we've released for months and months without fixing this, it doesn't make sense to keep it as a blocker.
comment:10 Changed 3 years ago by jdemeyer
- Description modified (diff)
- Component changed from packages to build
- Summary changed from upgrade -- if upgrading Cython run -ba instead of -b to Run sage -ba instead of sage -b after upgrading
- Priority changed from critical to blocker
- Report Upstream set to N/A
- Keywords upgrade cython added
comment:11 follow-up: ↓ 13 Changed 3 years ago by leif
This is just due to missing dependencies in module_list.py, so if everybody updating spkgs carefully checked them and added missing ones, this would be a non-issue. (And I consider it as such. Perhaps worth a work-around hint in the Developer's and / or Installation Guide.)
At least for upgrades to final versions, this should IMHO never be necessary.
comment:12 Changed 3 years ago by leif
P.S.: Explicitly touching some files in spkg-install that are contained in the extension modules' include_dirs can also avoid sage -ba, though of course a hack.
comment:13 in reply to: ↑ 11 ; follow-up: ↓ 14 Changed 3 years ago by jdemeyer
- Priority changed from blocker to major
- Description modified (diff)
- Summary changed from Run sage -ba instead of sage -b after upgrading to Run sage -ba instead of sage -b after upgrading Cython
Replying to leif:
This is just due to missing dependencies in module_list.py, so if everybody updating spkgs carefully checked them and added missing ones, this would be a non-issue. (And I consider it as such. Perhaps worth a work-around hint in the Developer's and / or Installation Guide.)
I created ticket #10124 to implement this.
comment:14 in reply to: ↑ 13 Changed 3 years ago by leif
comment:15 Changed 3 years ago by leif
Running sage -ba explicitly is not even necessary upon (true) Cython upgrades, though we could implement this in spkg/install.
We just have to make any Cython file / extension module depend on a single, distinct file of the Cython distribution (e.g. header) and preferably make sure this is only touched when really necessary.
Therefore it would make sense to use a Sage-specific file for such, which is created and managed by our spkg-install for Cython.
People upgrading the Cython package will best know if a complete rebuild will be necessary, depending on the Cython version found in the current installation subject to upgrade.
comment:16 Changed 8 months ago by jdemeyer
- Status changed from new to closed
- Reviewers set to Jeroen Demeyer
- Resolution set to worksforme
- Milestone changed from sage-5.4 to sage-duplicate/invalid/wontfix
Closing this since I haven't seen this problem at all recently.
