From: "Ludovic Courtès" <ludo@gnu.org>
To: "King, Spencer" <spencer.king@wustl.edu>
Cc: "74987@debbugs.gnu.org" <74987@debbugs.gnu.org>,
Nicolas Graves <ngraves@ngraves.fr>
Subject: [bug#74987] [PATCH 0/2] Some dependencies for julia-setfield
Date: Thu, 26 Dec 2024 12:38:55 +0100 [thread overview]
Message-ID: <877c7mwu5s.fsf@gnu.org> (raw)
In-Reply-To: <CH3PR02MB9746F7E8DDE165D98BEC439990032@CH3PR02MB9746.namprd02.prod.outlook.com> (Spencer King's message of "Tue, 24 Dec 2024 21:38:36 +0000")
Hi Spencer,
"King, Spencer" <spencer.king@wustl.edu> skribis:
> I agree that longer-term maintenance is a point of concern. Perhaps
> that will change if Julia begins to see more widespread adoption. I
> think one of the biggest issues facing Julia packaging is that there
> currently isn't the same level of interest as languages like Python. I
> also know that there have been some issues with packages not building
> reproducibly due to upstream issues with the internals of the Julia
> compiler, but I'm not going to pretend I have an in-depth
> understanding of that issue.
>
> I have seen your thread about your efforts to package a new version of
> Julia. It looks pretty complex and is definitely a major step up in
> complexity from any packages I've written so far. I think this comes
> back to the issue of interest, Julia just doesn't have the same level
> of interest as other languages in scientific computing so it can be
> challenging to find collaborators.
>
> Like you said, individual package upgrades have gone fine so far. I've
> done a few myself without issues. I agree that it probably won't last
> as the package set grows and we end up with more complex dependency
> trees. However, I imagine that is a similar issue faced by other
> package sets in Guix.
Fortunately, Julia is less of a nice today than it was a few years back.
Hopefully we’ll find more people to help.
Regarding long-term maintenance, have you looked at the importer that
was proposed a while back? (Cc’ing Nicolas.)
https://issues.guix.gnu.org/62202
I think we try and have an importer and updater in place to ease package
maintenance. Maybe the ‘juliahub’ importer (it seemed almost ready to
me), or maybe something else. It’s been instrumental in maintaining
other package sets.
Thanks for your feedback,
Ludo’.
prev parent reply other threads:[~2024-12-26 11:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 23:12 [bug#74987] [PATCH 0/2] Some dependencies for julia-setfield King, Spencer via Guix-patches via
2024-12-19 23:30 ` [bug#74987] [PATCH 1/2] gnu: Add julia-performancetesttools King, Spencer via Guix-patches via
2024-12-19 23:31 ` [bug#74987] [PATCH 2/2] gnu: Add julia-staticnumbers King, Spencer via Guix-patches via
2024-12-24 15:08 ` [bug#74987] [PATCH 0/2] Some dependencies for julia-setfield Ludovic Courtès
2024-12-24 21:38 ` King, Spencer via Guix-patches via
2024-12-26 11:38 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877c7mwu5s.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=74987@debbugs.gnu.org \
--cc=ngraves@ngraves.fr \
--cc=spencer.king@wustl.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.