#16434: Package d3.js
-------------------------------------+-------------------------------------
Reporter: tmonteil | Owner: tmonteil
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.3
Component: packages: | Resolution:
optional | Merged in:
Keywords: d3.js | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | 85c4ce7fd63d638545e65e05e73d7c84a2cc0e72
u/tmonteil/package_d3_js | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tmonteil):
Replying to [comment:5 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.
--
Ticket URL: <http://trac.sagemath.org/ticket/16434#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
