#9920 closed defect (fixed)
Ease SageNB development by providing hg commands, and extracting packages to /devel
| Reported by: | timdumol | Owned by: | jason, was |
|---|---|---|---|
| Priority: | major | Milestone: | sage-4.6 |
| Component: | notebook | Keywords: | |
| Cc: | jason, kcrisman | Merged in: | sagenb-0.8.4 |
| Authors: | Tim Dumol | Reviewers: | Jason Grout |
| Report Upstream: | N/A | Work issues: | |
| Branch: | Commit: | ||
| Dependencies: | Stopgaps: |
Status badges
Description
Jason Grout commented on #9822 about the relative difficulty/inconvenience of developing and applying patches for SageNB as compared to Sage. This ticket should fix it.
Attachments (4)
Change History (25)
Changed 11 years ago by
comment:2 follow-up: ↓ 3 Changed 11 years ago by
Does this mean that I should be using spkg-dist to make the spkg, instead of sage -spkg?
Also, does this set things up so that changes are reflected in the running notebook server? It seems that the spkg-dist just copies the hg repository there, but the notebook install is completely different.
comment:3 in reply to: ↑ 2 Changed 11 years ago by
Replying to jason:
Does this mean that I should be using spkg-dist to make the spkg, instead of sage -spkg?
Yes. That has been the case for a long time (c.f. SPKG.txt)
Also, does this set things up so that changes are reflected in the running notebook server? It seems that the spkg-dist just copies the hg repository there, but the notebook install is completely different.
I neglected to add that. Thanks for the notification. This new patch should fix it.
comment:4 Changed 11 years ago by
- Reviewers set to Jason Grout
- Status changed from needs_review to positive_review
Very nice! This seems to work well.
comment:5 Changed 11 years ago by
I'll start reviewing more notebook patches when this spkg is incorporated into sage!
comment:6 follow-up: ↓ 7 Changed 11 years ago by
- Status changed from positive_review to needs_info
The extcode, sage_scripts, and sage packages use Mercurial in their spkg-installs to merge changes into an existing repository. This could be more efficient than copying every file every time. Can we do that here?
Does the new spkg-install now install SageNB two places, under site-packages and devel? Is it practical to do just the latter?
comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 11 years ago by
Replying to mpatel:
The extcode, sage_scripts, and sage packages use Mercurial in their
spkg-installs to merge changes into an existing repository. This could be more efficient than copying every file every time. Can we do that here?
Can we make a new ticket for that?
In fact, I like this approach better (backup and copy), since it plays nicely with patch queues. The merge approach messes everything up if you forgot to pop all of your patches off.
Does the new
spkg-installnow install SageNB two places, undersite-packagesanddevel? Is it practical to do just the latter?
No, I don't think it installs twice (you can check the files to make sure). The setup.py develop installs under $SAGE_ROOT/devel/ and changes the site-packages folder to refer to that location.
comment:8 in reply to: ↑ 7 Changed 11 years ago by
Replying to jason:
Replying to mpatel:
The extcode, sage_scripts, and sage packages use Mercurial in their
spkg-installs to merge changes into an existing repository. This could be more efficient than copying every file every time. Can we do that here?Can we make a new ticket for that?
In fact, I like this approach better (backup and copy), since it plays nicely with patch queues. The merge approach messes everything up if you forgot to pop all of your patches off.
I agree with Jason.
Does the new
spkg-installnow install SageNB two places, undersite-packagesanddevel? Is it practical to do just the latter?No, I don't think it installs twice (you can check the files to make sure). The setup.py develop installs under $SAGE_ROOT/devel/ and changes the site-packages folder to refer to that location.
Actually, it does, but doing so is needed for the docs to show (static docs). We can make another ticket for that.
comment:9 Changed 11 years ago by
- Cc kcrisman added
comment:10 Changed 11 years ago by
- Status changed from needs_info to needs_review
I think both questions were answered, so I'm setting this back to positive review. It would be fantastic if it were included in the sagenb package for the next release.
comment:11 Changed 11 years ago by
- Status changed from needs_review to positive_review
comment:12 Changed 11 years ago by
By the way, another issue for another ticket: updating the developer's guide to include sagenb in the list of Mercurial repositories.
comment:13 Changed 11 years ago by
Sounds good. Thanks for the information. I'll add this to SageNB 0.8.4 at #10036.
comment:14 Changed 11 years ago by
- Merged in set to sagenb-0.8.4
comment:15 Changed 11 years ago by
- Resolution set to fixed
- Status changed from positive_review to closed
comment:16 Changed 11 years ago by
There's a problem with compiling from scratch, because $SAGE_ROOT/devel does not exist when sagenb-*.spkg is installed. I think doing mkdir -p will be enough.
Can someone add a new patch to fix this?
Changed 11 years ago by
Make $SAGE_ROOT/devel on install, if necessary. Apply on top of package extraction patch.
comment:17 follow-up: ↓ 18 Changed 11 years ago by
I've added a patch that I'm testing now.
comment:18 in reply to: ↑ 17 Changed 11 years ago by
comment:19 follow-up: ↓ 20 Changed 11 years ago by
I think we'll need to open a new ticket for making this link
ln -sf "$SAGE_ROOT/devel/sagenb-main" "$SAGE_ROOT/devel/sagenb"
relative. Otherwise, Sage won't start after I move/rename the root directory.
comment:20 in reply to: ↑ 19 ; follow-up: ↓ 21 Changed 11 years ago by
And maybe also add python setup.py develop to SAGE_LOCAL/bin/sage-location?
SageNB package. Extracts SageNB to $SAGE_ROOT/devel/ for ease of use.