Opened 7 years ago

Closed 7 years ago

Last modified 17 months ago

#16434 closed enhancement (fixed)

Package d3.js

Reported by: tmonteil Owned by: tmonteil
Priority: major Milestone: sage-6.3
Component: packages: optional Keywords: d3.js, sdl
Cc: ncohen, bonfroy Merged in:
Authors: Thierry Monteil Reviewers: Nathann Cohen
Report Upstream: N/A Work issues:
Branch: e0a214c (Commits) Commit: e0a214cc3324d36a5b87b6969acacc806c5427df
Dependencies: Stopgaps:

Description (last modified by tmonteil)

#14953 uses online 3d.js script. The aim of this ticket is to provide it as a package for offline use.

The source tarball can be downloaded at https://lipn.univ-paris13.fr/~monteil/hebergement/sage/d3js-3.4.8.tar.gz

Change History (21)

comment:1 Changed 7 years ago by tmonteil

  • Branch set to u/tmonteil/package_d3_js

comment:2 Changed 7 years ago by tmonteil

  • Commit set to 85c4ce7fd63d638545e65e05e73d7c84a2cc0e72
  • Component changed from packages: standard to packages: optional
  • Status changed from new to needs_review

The tarball (which was produced with sage-src) can be downloaded from https://lipn.univ-paris13.fr/~monteil/hebergement/sage/d3js-3.4.8.tar.gz


New commits:

85c4ce7d3js package creation

comment:3 Changed 7 years ago by ncohen

Yo !

Looks like you should not "move" an archive to upstream/. It looked a bit weird to be, and it seems that other sage-src script only fill the "src" directory with the right stuff. Like for ecl/ or ntl/ ...

Nathann

comment:4 follow-up: Changed 7 years ago by tmonteil

Well, i need to have the tarball in upstream/ to compute the new checksums.ini automatically. To my understanding the spkg-src script is used by the maintainer to ease rebuilding future versions, this is why i put the whole build process here (i also hesitated to create a ticket, push changes and ask for review on the fly ;). If you want, i can move it back to the work/ directory after building checksums.ini, but this does only affect the maintainer's upstream/ directory.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by ncohen

Yo !

Well, i need to have the tarball in upstream/ to compute the new checksums.ini automatically.

None of the other spkg do that.

To my understanding the spkg-src script is used by the maintainer to ease rebuilding future versions, this is why i put the whole build process here (i also hesitated to create a ticket, push changes and ask for review on the fly ;). If you want, i can move it back to the work/ directory after building checksums.ini, but this does only affect the maintainer's upstream/ directory.

First I think that it is meant to be the "src" directory, not the "work/" directory. Isn't sage -pkg meant to deal with that ? Either way I guess that the solution here should be global. If every package tries to solve this in a different way we are going nowhere O_o

Nathann

comment:6 Changed 7 years ago by ncohen

  • Status changed from needs_review to needs_info

comment:7 in reply to: ↑ 5 ; follow-up: Changed 7 years ago by tmonteil

Replying to ncohen:

Yo !

Hi Nathann and thanks for caring,

it is fun that i asked myself all those questions yesterday night, and i could not find an answer within the existing spkgs or the doc (another was whether i should call the spkg d3, d3js or d3_js).

find -name spkg-src -exec echo '{}' \; -exec cat '{}' \; | less

There seem to be no rule concerning the spkg-src script. The patterns you may discover between some of the spkg-src scripts only come from the fact that pieces are copied from one to another. For example, some script hardcode the version (e.g. ecl, so it needs to be modified by hand before being run), some write 'Run this after extracting the upstream sources in src/' (e.g. iml), some use curl (e.g ntl), other wget (e.g. cddlib), some create the final tarball (e.g. gap), some only fill a src/ directory (e.g. ntl), some apply patches while it is supposed to happen during spkg installation (e.g. lrcalc), some are written in python (e.g. maxima).

First I think that it is meant to be the "src" directory, not the "work/" directory.

Actually, the semantics of what represents 'src' is not even constant among existing scripts, which is more confusing than each having a different name. Some download the tarball within the src/ directory and work in there (e.g. singular), some extract the source in src/, some extract outside and move interesting stuff in src/ (e.g. gap_packages), some work directly within the upstream/ directory (e.g. autotools, which by the way lets the tarball in the maintainer's upstream/ directory).

Here, it is clear that work/ is where the script works (stuff that come here will not necessarily end in the produced tarball), it should even be called tmp_work/. I do not like to fetch things directely within the spkg directory, because then i have to remove them one by one (it is easier to remove a single subdirectory). I could create a src/ directory within the work/ directory, this would make sense, but since the tarball contains only two files ('d3.min.js' and 'LICENSE') i didn't think it was worth putting them in a separate directory before creating the tarball, but it is possible if you think it may help.

Well, i need to have the tarball in upstream/ to compute the new checksums.ini automatically.

None of the other spkg do that.

Actually, autotools spkg-src already puts its tarball in the upstream/ directory.

If some other maintainers like to do some complementary work by hand, it is fine, if they want me to do this as well by having only part of the maintenance script made public within spkg-src, then i can write my own proprietary meta-spkg-src script so that other maintainers of this package will also have to write their own, or work by hand.

I think this is in the spirit of the documentation that says : "This not only serves as documentation but also makes it easier to apply the same modifications to future versions". So, let us be the first to add this feature, so that future spkgs could benefit from this example and will have less hand work at each new release.

Either way I guess that the solution here should be global. If every package tries to solve this in a different way we are going nowhere O_o

I totally agree, but this is already the case. Adding confusion by using a name which already has different purposes only adds confusion.

Instead, we could have a specification somewhere since existing spkg-src are far from being consistent.

Isn't sage -pkg meant to deal with that ?

The sage-pkg script seems to be used for old-style spkg as it still uses mercurial.

comment:8 in reply to: ↑ 7 Changed 7 years ago by ncohen

Yoooooooo !

Hi Nathann and thanks for caring,

My pleasure. I am so sick of watching all my patches in needs_review and all the code I have yet to submit stuck because of endless nitpicking that I am actually glad to participate to some honest work... >_<

it is fun that i asked myself all those questions yesterday night, and i could not find an answer within the existing spkgs or the doc (another was whether i should call the spkg d3, d3js or d3_js).

find -name spkg-src -exec echo '{}' \; -exec cat '{}' \; | less

Hey by the way... Once a student of mine showed me a different way to do stuff like that, which is actually MUCH more powerful :

find . -iname "spkg-src" | while read line; do echo $line; cat $line; done

There seem to be no rule concerning the spkg-src script. The patterns you may discover between some of the spkg-src scripts only come from the fact that pieces are copied from one to another.

Okayokay.

remove a single subdirectory). I could create a src/ directory within the work/ directory, this would make sense, but since the tarball contains only two files ('d3.min.js' and 'LICENSE') i didn't think it was worth putting them in a separate directory before creating the tarball, but it is possible if you think it may help.

Well, I see no reason, you did the work right...

Actually, autotools spkg-src already puts its tarball in the upstream/ directory.

I see. Could you use SAGE_ROOT/upstream instead of ../../../../ btw ? I did this kind of things a long time ago and several generations of release managers cursed me for it :-P

Nathann

comment:9 Changed 7 years ago by ncohen

Just tried it, works for me. It woudl be cool if you can replace this ../../../ by a SAGE_ROOT, and then it can go.

Nathann

comment:10 Changed 7 years ago by tmonteil

Hmm, it does not work for me, did you set SAGE_ROOT somewhere ? Or did you run the script within sage -sh ?

comment:11 Changed 7 years ago by jhpalmieri

Try $SAGE_ROOT.

comment:12 Changed 7 years ago by git

  • Commit changed from 85c4ce7fd63d638545e65e05e73d7c84a2cc0e72 to 596e59a597b3f8e499f604f7bd50393e08f83a07

Branch pushed to git repo; I updated commit sha1. New commits:

596e59a#16434 : use $SAGE_ROOT instead of ../../../../

comment:13 Changed 7 years ago by tmonteil

  • Status changed from needs_info to needs_review

Done. The script forges SAGE_ROOT as "$(pwd)/../../../" in case the variable is not set as a backup. I also add set -e at the beginning in order not to mess everything up if something get wrong (e.g. if the archive can not be fetched by lack of network).

comment:14 Changed 7 years ago by ncohen

Funny, I did not know this option :-)

Nathann

comment:15 Changed 7 years ago by ncohen

  • Reviewers set to Nathann Cohen
  • Status changed from needs_review to positive_review

Thanks for this patch !

Nathann

comment:16 Changed 7 years ago by ncohen

Arggggggg.... Sorry I just noticed something... Could you build your package in a different way ? Right now when you run "tar xvzf tar xzvf d3js-3.4.8.tar.gz" the files are extracted into the current directory, and that's a bit messy :-/

Nathann

comment:17 Changed 7 years ago by git

  • Commit changed from 596e59a597b3f8e499f604f7bd50393e08f83a07 to e0a214cc3324d36a5b87b6969acacc806c5427df
  • Status changed from positive_review to needs_review

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

e0a214c#16434 files in tarball are in a d3js-$VERSION subdirectory

comment:18 Changed 7 years ago by tmonteil

  • Authors set to Thierry Monteil
  • Description modified (diff)

You are right, for two files i was thinking that is was not an issue since the build dir get destroyed anyway, but i didn-t think a human could be interested in unpacking the tarball. I updated the source tarball accordingly.

comment:19 Changed 7 years ago by ncohen

  • Status changed from needs_review to positive_review

Thanks ! It still works, sooo.... :-)

Nathann

comment:20 Changed 7 years ago by vbraun

  • Branch changed from u/tmonteil/package_d3_js to e0a214cc3324d36a5b87b6969acacc806c5427df
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:21 Changed 17 months ago by tmonteil

  • Keywords sdl added
Note: See TracTickets for help on using tickets.