From: Chema Alonso <nimiux@gentoo.org>
To: gentoo-soc@lists.gentoo.org
Cc: Crystalsun <crystalsun@protonmail.com>,
common-lisp@gentoo.org, gentoo-lisp@lists.gentoo.org
Subject: [gentoo-lisp] Re: [gentoo-soc] GSoC suggestion - Emerge or some of the Portage features implemented in Common Lisp
Date: Wed, 28 Mar 2018 14:58:11 +0000 [thread overview]
Message-ID: <20180328145811.GA15433@woodpecker.gentoo.org> (raw)
In-Reply-To: <20180325233447.027b4f76c04019b7ef7dd833@gentoo.org>
This was already addressed in the gentoo-lisp mailing list [1].
Sounds good but the Common Lisp project lacks the manpower to give
support to this.
Regards.
[1] https://archives.gentoo.org/gentoo-lisp/message/3bdcbcc163666451ec6c7a9ec9297142
On Sun, Mar 25, 2018 at 11:34:47PM +0300, Andrew Savchenko wrote:
> Hi!
>
> On Sat, 24 Mar 2018 04:48:53 -0400 Crystalsun wrote:
> > Hello everybody!
> > I want to share some thoughts on a project that can be
> > implemented during Google SUmmer of Code.
>
> Thank you for your interest in the Gentoo GSoC.
>
> > So, moving on to the proposal - I suggest that implementing
> > emerge or some of its features in Common Lisp may be a great thing.
>
> I'm not a Lisp guy, so I'm CC'ing Lisp community.
>
> > The first and main reason for that is the interactiveness Common
> > Lisp provides (and Python doesn't).
>
> You should know that the portage (where the emerge tool belongs) is
> not the only one implementation. We have Gentoo Package Manager
> Specification (PMS)[1] detailed enough to implement alternative
> implementations. Right now we have three of them: portage[2],
> pkgcore[3] and paludis[4]; the first two are in python, the later
> one is in C++.
>
> > For example, when emerging a package, if an error occures, the
> > whole process will die since the merge of the current atom.
> > However, if emerge was written in Common Lisp, it could be possible
> > to interactively debug the error and continue the process, which,
> > overall, means more user control of what's happening and better
> > hotfixes, thanks to the fact that the REPL is part of the language
> > itself, not provided by the *outer environment*.
>
> I do not understand what you mean as interactiveness. Python
> support interactive execution shell with ipython. But it should not
> be an issue here anyway, see below.
>
> What exactly do you mean as an error? If we are talking about
> internal portage crash, such cases are extremely rare and are
> usually promptly fixed.
>
> If you mean failed dependency calculation, this usually happens due
> to impossibility of building dep graph for present packages, USE
> flags, package manager (PM) options and other constraints. In order
> to fix them changes must be made (e.g. user should change some USE
> flags) and dependency tree graph needs to be build again. This is
> the most time consuming part and it doesn't matter if PM will be
> restarted as an application or not, because most time will be spent
> on graph building, not on application restart.
>
> If you mean failed package builds, there is no need to start emerge
> from scratch. It has --resume option to resume operation,
> --skipfirst may be used to skip last failed package. Option
> --keep-going allows to try to build packages as long as possible:
> after a package build failure a dependency tree is being
> recalculated in order to rebuild all packages not blocked by one
> failed to build.
>
> So I don't understand what knew user visible features will be
> available thanks to Lisp.
>
> > Nevertheless, changing emerge also means changing ebuilds, which
> > is truly a big change.
>
> Why ebuilds must be changed? The PMS is PM agnostic. It doesn't
> matter using what language PM will be implemented: PMS defines
> abstract API and this API can be implemented in any Turing-complete
> programming language.
>
> > Thus, I understand it may be too hard/long to implement, so a
> > compromising, yet useful solution might be available. For instance,
> > it could be fairly great to localize some task Portage is slow/bad
> > at, and reimplement it (what about resolving dependencies
> > interactively?). That might be a good place to start already.
>
> Frankly I really doubt that Lisp will be faster than Python for
> this task. Both are quite high level languages.
>
> Of course you idea is far out of the scope of the GSoC time frame,
> but if Lisp team will found it useful, maybe you can start with
> some skeleton implementation.
>
> [1] https://projects.gentoo.org/pms/6/pms.html
> https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification
> [2] https://wiki.gentoo.org/wiki/Project:Portage
> [3] https://github.com/pkgcore/pkgcore
> [4] https://wiki.gentoo.org/wiki/Paludis/Guide
> https://paludis.exherbo.org/
>
>
> Best regards,
> Andrew Savchenko
parent reply other threads:[~2018-03-28 14:58 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20180325233447.027b4f76c04019b7ef7dd833@gentoo.org>]
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=20180328145811.GA15433@woodpecker.gentoo.org \
--to=nimiux@gentoo.org \
--cc=common-lisp@gentoo.org \
--cc=crystalsun@protonmail.com \
--cc=gentoo-lisp@lists.gentoo.org \
--cc=gentoo-soc@lists.gentoo.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox