Why not migrate Portage to C language?

[Naib]

I'd rather use clojure than python for a dynamic language with optinoal typing.

But you haven't done anything so this reply is moot. You would do it in Haskel BUT you haven't. What we have is functional and unless someone attempts to replace it, it won't.
Look at how long NDF take to come along and even then it hasn't replaced yum.

Even of you implemented the PMS in whitespace there is zero guarantee that it will provide a solution that kicked off these multiple critism (ie perl) because part of the problem is perl itself and having a dedicated cleaning script, which you need to run what? Every couple of years AT THAT is not the end of the world.

[C5ace]

With C, you have to worry about violating memory boundaries constantly even if a C program compiles.
A C program crashes if you are not careful about memory boundaries. Just writing a simple for loop in C can lead to buffer overflow.
People who work on computer security know how hard it is to write correct C programs that don't crash or lead to buffer overflow.
C requires a lot of discipline which is expensive. With haskell, you don't have to worry about it.
If you don't have the budget of NASA, maintaining a haskell program in a multi-person project is substantially cheaper and faster than maintaining a C program.

I've been writing C for about forty years, professionally for 25. I NEVER had those problems. Maybe code cowboys did, professionals didn't. You are spreading FUD.

I concur with Tony0945. Been writing C private and professionally since 1988. Would not touch any other language, including C++ and Python with a barge pole.

[CasperVector]

I've been writing C for about forty years, professionally for 25.

[OT]So you began doing it professionally when I was around 4 y/o [/OT]

[Tony0945]

Probably before you were born. Professional use was first. early '80s My boss sent me to an AT&T seminar to see what this C language was all about. we mostly used Z80 assembly language at that time. We then started using it on new 8088 projects. I did port it to Z80, no floating point, no bit-fields. I was kind of proud of the block swapping code I wrote to get around the memory limitations.

[alexander-n8hgeg5e]

If something really needs speedup, python can be extended with c-modules.

[Zucca]

Not knowing much about the internals of different programming languages...
Rust and Go sound good.
I still voted "I don't care". Although removing python depency from Gentoo base install would be a plus in my eyes.

[asturm]

Rust and Go sound good.

Those two are representative of all that is wrong in today's programming world

[Zucca]

Rust and Go sound good.

Those two are representative of all that is wrong in today's programming world

I have "faith" those could be better choices than python.

[Hu]

If their core developers were not dead set on following packaging worst practices, maybe. I suggest you try to install Rust straight from source, without using a prebuilt Rust as a shortcut. Before you start, uninstall any rust or rust-bin packages currently installed, then mask rust-bin.

[Ant P.]

Rust and Go sound good.

Those two are representative of all that is wrong in today's programming world :lol:

I have "faith" those could be better choices than python. :D

eshowkw rust go python tells a different story.

[mv]

If their core developers were not dead set on following packaging worst practices

It is best practice to write a general-purpose language compiler/interpreter in its own code. AFAIK, both languages have public (open source) boot-strap procedures available, but it lies in the nature of things that they are cumbersome and something most people do not want to have on their usual machines: For go, AFAIK this is the GNU compiler collection go which bootstraps itself via the gcc compiler and has probably no much other purpose than being a bootsrap-compiler, and for rust this is rust-build. That gentoo does not optionally offer building by rust-build is a gentoo decision, I suppose.

[Muso]

Rust and Go sound good.

Those two are representative of all that is wrong in today's programming world

What's wrong with Go?

I'm perfectly happy with Portage as is, but I'm just curious as to why you seem to dislike Go.

[Ionen]

Clearly portage should be rewritten in JavaScript+php with a required modern browser frontend, the web server would install packages with a CGI+rust backend. The build system should use dev-ruby/rake and also use perl and python for generate a few files. A Go module could be used for dependency calculations integrated after someone else made it. I recommend a dependency on haskell to build the man page.

[fedeliallalinea]

Clearly portage should be rewritten in JavaScript+php with a required modern browser frontend, the web server would install packages with a CGI+rust backend. The build system should use dev-ruby/rake and also use perl and python for generate a few files. A Go module could be used for dependency calculations integrated after someone else made it. I recommend a dependency on haskell to build the man page.

No java

[Zucca]

I'll propose Portage to be rewritten in Whitespace.

[mv]

I'll propose Portage to be rewritten in Whitespace.

That's an old suggestion. IIRC immediately after the suggestion to use Brainfuck.

[mv]

But to write something serious: Most part of portage is actually bash, except for the dependency resolver. And this is the slow part. There once was a suggestion to use a SAT solver library for dependency resolving. Unsurprisingly (to me) this project was never finished, but if somebody really wants to make portage faster, this is the way to go IMHO.

[Naib]

plenty of suggestions, plenty of criticism but not alot of doing This is why it will stay as python and fundamentally there is nothing wrong with that.

[Ionen]

plenty of suggestions, plenty of criticism but not alot of doing This is why it will stay as python and fundamentally there is nothing wrong with that.

Yeah, if someone/people actually rewrote portage in another language that is compatible with current implementation it could eventually be offered as an alternative, and if deemed better could replace it after sufficient testing.

But asking current devs to drop everything they've done and rewrite it, I don't think so

List of features to re-implement has also gotten long, so the idea of extending the current implementation (like a faster dependency calculation algorithm that "could" be written in C) is also more reasonable, but again, someone has to do it. Not that this helps if want a python-less system (or worse, bash-less), but that's how things are.

[Hu]

If their core developers were not dead set on following packaging worst practices

It is best practice to write a general-purpose language compiler/interpreter in its own code.

The inability to build these packages without having already built them is only the beginning of what's wrong with them, although it is a major first step. Rust's "recommended" install instructions pushing people to curlpipesh is a good second step in case anyone was thinking about trusting them to treat packaging seriously.

AFAIK, both languages have public (open source) boot-strap procedures available, but it lies in the nature of things that they are cumbersome and something most people do not want to have on their usual machines: For go, AFAIK this is the GNU compiler collection go which bootstraps itself via the gcc compiler and has probably no much other purpose than being a bootsrap-compiler, and for rust this is rust-build. That gentoo does not optionally offer building by rust-build is a gentoo decision, I suppose.

I have never seen anyone mention rust-build, and the Rust recommended install instructions make no mention of it either. A search for "rust-build" doesn't turn up anything with that name, but does lead to the Rust github page, which recommends a Python script that, by their own documentation, doesn't even have dependency tracking set up correctly:

If you have already built rustc, then you may have to execute rm -rf build for subsequent configuration changes to take effect. Note that ./x.py clean will not cause a rebuild of LLVM, so if your configuration change affects LLVM, you will need to manually rm -rf build/ before rebuilding.

Later:

Stage 0: the stage0 compiler is usually (you can configure x.py to use something else) the current beta rustc compiler and its associated dynamic libraries (which x.py will download for you).

I will grant that the parenthetical note might, or might not, apply only to the dynamic libraries. If it does, then it's not clear where the current beta rustc compiler would come from.

From the readme, as rendered by the Github repository:

Since the Rust compiler is written in Rust, it must be built by a precompiled "snapshot" version of itself (made in an earlier stage of development). As such, source builds require a connection to the Internet, to fetch snapshots, and an OS that can execute the available snapshot binaries.

From that, I don't know what Gentoo could do that is meaningfully different from the current approach of depending on a rust-bin that is downloaded and used to compile the rust sources.

[mv]

Rust's "recommended" install instructions pushing people to curlpipesh is a good second step in case anyone was thinking about trusting them to treat packaging seriously.

Oh yeah, it is so much more clever to follow instead the python recommendation and use pip.

I don't know what Gentoo could do that is meaningfully different from the current approach of depending on a rust-bin that is downloaded and used to compile the rust sources.

One could write a full bootstrap (I thought rust-build were such, but I might be wrong). Yes, bootstrapping to a different architecture (which would mean a full bootstrap) is not simple, and not even gcc can do that easily. go only has it simpler because they have become part of an "established" compiler chain.

[pjp]

plenty of suggestions, plenty of criticism but not alot of doing :) This is why it will stay as python and fundamentally there is nothing wrong with that.

Yep. Not everyone has the skillset. That doesn't mean an implementation or other choices are beyond constructive criticism. The main reason I'd prefer to not rely on python can be exhibited in the python 2.7 retirement as well as the frequent updates of newer versions.

[Zucca]

Oh yeah, it is so much more clever to follow instead the python recommendation and use pip.

I can sense many installations get broken because people run such programming language specific package managers as root.

[Hu]

Rust's "recommended" install instructions pushing people to curlpipesh is a good second step in case anyone was thinking about trusting them to treat packaging seriously.

Oh yeah, it is so much more clever to follow instead the python recommendation and use pip.

Pip, for all its faults, natively supports installing packages to a user private area or a virtual environment. A curlpipesh, almost by definition, could be anything, and could be something else tomorrow, so even if the currently served script is good (which I very much doubt), it could be something better or worse by the time someone else looks at it. For that reason, it is my opinion that a curlpipesh is always a bad solution, no matter what problem is under discussion. That does not necessarily preclude offering curlpipesh as a fallback, but when curlpipesh is the recommended solution, that reduces my trust in all the other packaging related advice from that speaker.

Citing pip is not relevant here, because the download page for the Python interpreter makes no mention of it and because it is not the preferred way to install Python (indeed, as far as I know, pip cannot be used to install Python, only to install selected Python packages that are hosted on PyPI or a compatible index). Even if both of those were false and Python were very difficult to package, the existence of bad practice in the Python community does not excuse the Rust community choosing actions that are so directly contrary to good packaging.

[Dr.Willy]

@mv if you wish to short-circuit that discussion with Hu: https://forums.gentoo.org/viewtopic-p-8 ... ml#8334612