>> [3] >> #+begin_example scheme >> In current input: >> 12:3 12 (_) >> In guix/store.scm: > > [...] > >> 619:8 4 (_ #(#(#(#) "/gnu…" …) …)) >> 626:19 3 (_ #(#(#(#) "/gnu…" …) …)) >> 155:9 2 (_ #(#(#(#) "/gnu…" …) …)) >> 223:20 1 (proc #(#(#(#) "/…" …) …)) >> In unknown file: >> 0 (%resolve-variable (7 . %guix-register-program) #) >> #+end_example >> But how would I know what a "good" guix inferior commit is for all of >> these packages? > > Let’s fix ideas and let’s say you are interested by the package > python-foo at the version 1.2.3. This package depends on python-bar at > version x.y.z available at commit range 12345-67890 and on python-baz at > version m.n available at commit range ABCDE-FGHIJ. > > Then there is no commit where python-bar *and* python-baz are both at > the correct versions (resp. x.y.z and m.n.). In other words, the 2 > commit ranges 12345-67890 and ABCDE-FGHIJ do not overlap. > > Is it your use case? I do not think so. I have three different scenarios I'm working with: 1. python-foo does not exist in guix :: So I use guix import to give me a package definition and work from there (so far this is okay, but if it weren't because of its dependencies I see where we might need to follow your hypothetical). 2. python-foo does exist in guix, but the desired version is in the past :: So I (attempt to) use a guix inferior from a channel where it was defined (this is where I have issues, but I assume that if guix had a definition for it, then python-bar and python-baz would both be available in the entire commit range that it defines python-foo). 3. python-foo does exist in guix, but I need a newer version :: I inherit from the old version, changing the necessary fields (like 1. I see where we would need to follow the hypothetical, but I haven't seen any missing dependencies errors). I successfully made the channel https://github.com/branjam4/cna-python (with packages from 3. and 1.) when I last worked on this. Hopefully having a successful channel build isn't deceiving me, but I thought given the successful build that I got lucky with needing to figure out dependencies. My primary block is this "unregisted program" error I get when using guix inferiors that I'd like to add to my manifest. > From my experience, one simple way to start is: > > guix time-machine --commit= \ > -- build -L > > where is an old Guix commit providing bunch of dependencies used > by of interest defined in the folder > . > > A channels.scm file with the option ’--channels/-C’ seems even better. Hmm, my end goal is to make /something/ that will be simple for people with minimal assumed experience in guix (my professor, for example) to run in a virtual machine with guix and direnv available, so they can pull a git repository, then follow code examples from the book without focusing on dependency building (there would be the initial cost of waiting for things to build the first time, though). Assuming time-machine works, is it straightforward to make a profile from it (or something else enabling direnv to understand what I want when I go into the cna-python directory)? That was something I missed while reading the time-machine part of the manual. >> Believing guix could more faithfully/cleanly reproduce the environment >> from the book than my former approach using pip, I: >> + imported/wrote definitions for packages not in guix > > Usually, this is done via the option “--load-path” or Custom Channels. > > True, I have older generations with my repo as a channel: #+BEGIN_EXAMPLE bash cna-python 35290a1 repository URL: https://github.com/branjam4/cna-python.git branch: master commit: 35290a12d09ad528babba6052d37bcd09bd4c9a4 guix 0e1b095 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 0e1b0958bde5ccc34a4fed9a09cf949d5f9c9519 #+END_EXAMPLE Though with recent guix pulls it fails at that same commit, saying that syntax has changed. I'm not as concerned about that at the moment compared with the guix inferior channels issue though. >> + wrote inferiors for older versions of packages that were in guix. > > You might be interested by this Channel: > > > I see. First looked at this channel a few days ago, but went straight to its package definitions and only skimmed the readme (which at the beginning mentioned using software from ten years ago, throwing me off from accepting it for my use case). Under the "Hacking" section it says: > It makes most sense to add software dating back to before 2019, around > the time where time travel became possible. The packages I'm trying to reproduce would have been current in mid 2017. Does that mean neither guix inferiors nor guix time-machine will work reliably for commits in that year? > BTW, a tool to find the range of commit where one specific version is > available is the Data Service. Give a look at: > > > Thanks, this definitely seems more robust than my git log grepping! > I have tried to write a script for my personal needs running via “guix > repl”. It fetches the JSON file from the Data Service, which give the > commit range for the required version per package. Then I have not > finished it (yet) but the idea was to be able to spot out the commit > providing all the packages at the required versions, i.e., the > intersection. Pieces of the necessary material is in guix/git.scm. > > Ah, definitely intriguing. While I was on my grepping expedition I wondered whether I could use one or two old guix commits instead of five, so I like this concept. > Being on a foreign distro does not change. The main difference between > between foreign and native is only about services, not packages. Figured, thank you for confirming. --Brandon