<abathur>
I've been working on a "resolver" or "linker" for external dependencies in shell scripts (along with a Nix build function). I've got it to the point where I'm using it to compose a chain of dependent shell scripts into my bashrc. I think it's a big leap towards making a case for Nix as a good package manager for shell projects. Fishing for some help/review/critique and even good-natured
<abathur>
bikeshedding on how the Nix fraction is structured. Fishing for some help/review/critique and
<abathur>
oops
<abathur>
ignore the end-fragment :)
<cole-h>
For someone to review would require a link ;^)
<cole-h>
abathur: (hadn't taken a look until now) That looks pretty cool. Assuming all the py2 deps are because of oil?
<abathur>
yeah
<abathur>
it's a bit idiomatic
<abathur>
I spoke with gc about this
<abathur>
basically he's using a forked python 27, iinternally, which he feels (after having converted up to python 3) is actually more productive for his purpose of building a shell
<abathur>
wrt to string/byte/unicode handling
<cole-h>
Yeah, I remember reading something along those lines in the docs somewhere
<cole-h>
I just always go wide-eyed when I see py2 deps (in this case, it's understandable)
<abathur>
nod
<abathur>
I did, too
<abathur>
I had a long chat with andy of oilshell about it
<abathur>
can find the lnik if you want
<cole-h>
I'm sure I can find it if I search the zulip (unless it was elsewhere)
<cole-h>
abathur: Assuming it's the "future/fate of python2 code" stream-thing (I dunno what it should be called) in oil-dev?
<abathur>
it's on zulip, yeah
<abathur>
thread
<abathur>
(and yes, that's it)
<cole-h>
abathur++ Good reading material for the next time I have nothing to do :P Thanks.
<{^_^}>
abathur's karma got increased to 1
<abathur>
my working assumption is that if it's useful enough of a tool, and if py27 becomes a problem, the work-hours to convert it will be available
<abathur>
and if not, it won't deserve the upconvert :)
<abathur>
the TLDR of the thread is that he has converted it up to 3 before, though, and doesn't think it would be too bad to do so again
<cole-h>
Interesting. Thanks again.
<abathur>
:]
init_6 has quit [Ping timeout: 264 seconds]
andi- has quit [Remote host closed the connection]
<FRidh>
don't think anybody merged master into staging-next
<FRidh>
i haven't been around much last couple of weeks
<worldofpeace>
yeah, I think lovesegfault mentioned this to me
<jtojnar>
Fridh I merge master → staging-next → staging every few days
<jtojnar>
do you usually merge staging → staging-next before triggering the eval?
<lovesegfault>
Yeah, I did
<lovesegfault>
FWIW: I'd love to help with the whole staging process if you're not having time, FRidh
<FRidh>
jtojnar: that's good for keeping the branches up to date. In this case, staging-next did not contain anything new, so staging had to be merged into it. I just did this and opened a PR for the new staging-next
<{^_^}>
#83618 (by FRidh, 6 minutes ago, open): Staging next
<FRidh>
lovesegfault: good to hear. As jtojnar described, its basically doing those merges often (i try to do it daily but was away for awhile). And then, when staging-next looks good (about once a week) merge it into master and staging goes into staging-next again
<lovesegfault>
FRidh: got it; what's the process to deal with large breakages while _still_ on `staging-next`?
<FRidh>
also, PR's targetting staging are often not merged (but they can!), so typically going through those is a good idea either
<lovesegfault>
i.e. is it okay to revert PRs, etc
<FRidh>
if no fix is available or available and tested soon, then indeed revert.
<lovesegfault>
got it
<FRidh>
often it is also necessary to restart jobs on hydra. It's not uncommon that e.g. llvm fails on arm due to timeout
johnny101 has quit [Quit: Konversation terminated!]
<jtojnar>
samueldr that would be just running result/bin/hydra-eval-jobs pkgs/top-level/release.nix (or whatever expression is listed in the configuration tab of the jobset)?