<korvo>
mjacob: It's marked insecure. Treewide policy for EOL stuff. I've chosen Approach 3 and forked that expression in a way that doesn't build a python27Packages.
<korvo>
Instead, any RPython packages are "installed" by unpacking them to a single directory and using that as a PYTHONPATH. They're only needed per-build, so it's not worth trying to run pip in a build step.
<mjacob>
what does “marked insecure” imply?
<korvo>
In practice, it means that any users have to explicitly add "python-2.7.18" to a list of permitted packages. It's not an actual security issue.
<mjacob>
korvo: i’m a bit confused about your statement that the rpypkgs approach is like perl’s miniperl approach. what’s the relationship between “the perl build system is written in perl, so it compiles a stripped down version of it first” and “i’ve forked the python 2.7 nix expression”?
<korvo>
mjacob: First we compile a Python 2.7 that's really only suitable for building PyPy, then we compile a PyPy 2.7 that's really only suitable for building RPython stuff.
<korvo>
Approach 1 is to have a tarball with a PyPy that I already built earlier offscreen. Approach 2 is similar but the tarball comes from some Debian developer.
<mjacob>
korvo: Thanks for the clarification. I was confused because I factored the problem into a different sequence of subproblems. The first is getting some executable “Python 2.7 that's really only suitable for building PyPy”. That’s the only part where the approaches differ in my model (getting a prebuilt tarball vs. using a nix derivation). The second is “then we compile a PyPy 2.7 that's really only
<mjacob>
suitable for building RPython stuff”. Does your idea of approach 1/2 skip “then we compile a PyPy 2.7 that's really only suitable for building RPython stuff”?
<korvo>
mjacob: I don't know. I mean, I see what you're getting at. Yeah, ideally, for any desired target architecture, somebody's already produced a PyPy binary that we can yoink and patch. And if so, then that binary should be directly usable for RPython builds.
<korvo>
The reason for that intermediate step is that I kind of expected to be the one producing the tarball. So I would want to build a *minimal* PyPy with --translation-modules in order to have a smaller tarball with fewer dependencies to include.
<mjacob>
The following will probably not help for bootstrapping PyPy, but it might still be interesting for you. I’ve been working on the proof of concept of a system similar to Nix that is completely (output-) content-addressed instead of “input-addressed” like Nix. Bootstrapping works by building the relevant packages on two already existing systems in a Docker container (I’ve chosen an old Debian version
<mjacob>
and a new rolling-release distribution to increase confidence in the approach). The produced sets are called “stage 1”. Most of the built packages are different between the two stage 1 sets because the build systems have different toolchains. Each of these sets of built packages is used to build the packages again. The result is called “stage 2”. If everything was done properly, the stage 2 sets
<mjacob>
should be identical. This unique stage 2 set is used to build stage 3, which should be identical to stage 2. If that’s the case, the built packages are considered to be independent enough of the original systems.
<mjacob>
korvo: my previous message was split. it should start with “The following” and end with “original systems.”
<korvo>
Oh, exciting! Very cool. That's much cleaner than what I did, which was to manually build a stage 4 and compare it to stage 3.
<mjacob>
korvo: in rpypkgs, you mean?
<mjacob>
the problem with nix is that the paths in the store are always different because of the input-addressed model
<mjacob>
(at least it has been like this in the past, not sure how far their content-adressable storage project is nowadays)
<korvo>
Well, not in rpypkgs exactly. I only did it once as a test, because building PyPy takes so long and I am very impatient.
Dejan has quit [Quit: Leaving]
Julian has joined #pypy
jcea has joined #pypy
Julian has quit [Quit: leaving]
jcea has quit [Ping timeout: 252 seconds]
jcea has joined #pypy
glyph has quit [Remote host closed the connection]