1 |
Hi! |
2 |
|
3 |
On Sat, 24 Mar 2018 04:48:53 -0400 Crystalsun wrote: |
4 |
> Hello everybody! |
5 |
> I want to share some thoughts on a project that can be |
6 |
> implemented during Google SUmmer of Code. |
7 |
|
8 |
Thank you for your interest in the Gentoo GSoC. |
9 |
|
10 |
> So, moving on to the proposal - I suggest that implementing |
11 |
> emerge or some of its features in Common Lisp may be a great thing. |
12 |
|
13 |
I'm not a Lisp guy, so I'm CC'ing Lisp community. |
14 |
|
15 |
> The first and main reason for that is the interactiveness Common |
16 |
> Lisp provides (and Python doesn't). |
17 |
|
18 |
You should know that the portage (where the emerge tool belongs) is |
19 |
not the only one implementation. We have Gentoo Package Manager |
20 |
Specification (PMS)[1] detailed enough to implement alternative |
21 |
implementations. Right now we have three of them: portage[2], |
22 |
pkgcore[3] and paludis[4]; the first two are in python, the later |
23 |
one is in C++. |
24 |
|
25 |
> For example, when emerging a package, if an error occures, the |
26 |
> whole process will die since the merge of the current atom. |
27 |
> However, if emerge was written in Common Lisp, it could be possible |
28 |
> to interactively debug the error and continue the process, which, |
29 |
> overall, means more user control of what's happening and better |
30 |
> hotfixes, thanks to the fact that the REPL is part of the language |
31 |
> itself, not provided by the *outer environment*. |
32 |
|
33 |
I do not understand what you mean as interactiveness. Python |
34 |
support interactive execution shell with ipython. But it should not |
35 |
be an issue here anyway, see below. |
36 |
|
37 |
What exactly do you mean as an error? If we are talking about |
38 |
internal portage crash, such cases are extremely rare and are |
39 |
usually promptly fixed. |
40 |
|
41 |
If you mean failed dependency calculation, this usually happens due |
42 |
to impossibility of building dep graph for present packages, USE |
43 |
flags, package manager (PM) options and other constraints. In order |
44 |
to fix them changes must be made (e.g. user should change some USE |
45 |
flags) and dependency tree graph needs to be build again. This is |
46 |
the most time consuming part and it doesn't matter if PM will be |
47 |
restarted as an application or not, because most time will be spent |
48 |
on graph building, not on application restart. |
49 |
|
50 |
If you mean failed package builds, there is no need to start emerge |
51 |
from scratch. It has --resume option to resume operation, |
52 |
--skipfirst may be used to skip last failed package. Option |
53 |
--keep-going allows to try to build packages as long as possible: |
54 |
after a package build failure a dependency tree is being |
55 |
recalculated in order to rebuild all packages not blocked by one |
56 |
failed to build. |
57 |
|
58 |
So I don't understand what knew user visible features will be |
59 |
available thanks to Lisp. |
60 |
|
61 |
> Nevertheless, changing emerge also means changing ebuilds, which |
62 |
> is truly a big change. |
63 |
|
64 |
Why ebuilds must be changed? The PMS is PM agnostic. It doesn't |
65 |
matter using what language PM will be implemented: PMS defines |
66 |
abstract API and this API can be implemented in any Turing-complete |
67 |
programming language. |
68 |
|
69 |
> Thus, I understand it may be too hard/long to implement, so a |
70 |
> compromising, yet useful solution might be available. For instance, |
71 |
> it could be fairly great to localize some task Portage is slow/bad |
72 |
> at, and reimplement it (what about resolving dependencies |
73 |
> interactively?). That might be a good place to start already. |
74 |
|
75 |
Frankly I really doubt that Lisp will be faster than Python for |
76 |
this task. Both are quite high level languages. |
77 |
|
78 |
Of course you idea is far out of the scope of the GSoC time frame, |
79 |
but if Lisp team will found it useful, maybe you can start with |
80 |
some skeleton implementation. |
81 |
|
82 |
[1] https://projects.gentoo.org/pms/6/pms.html |
83 |
https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification |
84 |
[2] https://wiki.gentoo.org/wiki/Project:Portage |
85 |
[3] https://github.com/pkgcore/pkgcore |
86 |
[4] https://wiki.gentoo.org/wiki/Paludis/Guide |
87 |
https://paludis.exherbo.org/ |
88 |
|
89 |
|
90 |
Best regards, |
91 |
Andrew Savchenko |