<ekleog>
Hmm… is /usr/bin/env absent inside the build sandbox? looks like it to me but… why?
<ekleog>
(asking for python tests that currently need it to work
<ekleog>
)
<gchristensen>
only /bin/sh is in the sandbox, you'll need to patchShebangs
<ekleog>
well it's in an executable that's auto-generated by the test harness :/
<gchristensen>
womp womp
<ekleog>
good news is I'm maintainer of the upstream source code so I can just work around it myself as the release isn't cut yet, but I'm wondering why /usr/bin/env isn't there
<ekleog>
i mean it's basically the same as /bin/sh -c "$*" or something vaguely similar
<samueldr>
it makes "any" of the given binaries on path be called rather than a specific patched-in one
<samueldr>
(in my opinion /bin/sh being in the build sandbox is probably not good either)
<ekleog>
right, but /bin/sh does the same, doesn't it?
<abathur>
just two sticks and some tinder
<ekleog>
oh ok if we're getting /bin/sh away it makes sense, but I guess the current state looks inconsistent to me
<samueldr>
I don't think /bin/sh is going away, that was my personal opinion :)
<ekleog>
'nyway back to fixing upstream, it was /usr/bin/env sh so it's not a big deal to replace it with /bin/sh anyway :)
<ekleog>
(just that it means i'll have more pushing to test-pypi to do and that's a pain because now the version numbers will be a mess but whatever my problem :p)
ris has quit [Ping timeout: 265 seconds]
rajivr has joined #nixos-dev
<sterni>
samueldr: /usr/bin/env has also some *slightly* cursed features to work around the shebang limitation that you can only pass one argument
<sterni>
and you can set environment variables
<samueldr>
hm?
<samueldr>
ekleog said "does the same" :)
<sterni>
whoops misread
<sterni>
/usr/bin/env is wild, wonderful and a bit cursed
<sterni>
after reading the man page I was happy not to have been the person writing patchshebangs :p
<ekleog>
sterni: well, I mean, this is possible today
<ekleog>
:b stdenv.mkDerivation { name="foo"; src=/tmp/foo; buildPhase="echo 'before test'; /bin/sh -c 'env -i sh -c \"echo test success\"';"; }
<ekleog>
Now I don't know what kind of purity blocking it by default gets us, but it's probably nothing awesome given what it does is basically done by sh already — but as you said trying to work around its lack is certainly going to be a bit curse
<ekleog>
d
<ekleog>
samueldr: wondering, how many times have you been confused for me? 'cause I feel like it happened a few times in the past few days x)
<gchristensen>
while we're at it, let's add /bin/bash
<samueldr>
ugh
<ekleog>
do we have concrete use cases for /bin/bash being available in the sandbox?
<samueldr>
ekleog: I don't think too often... but really I think it's people reading quickly and mismatching lines and names
<gchristensen>
imo we should remove /bin/sh from the sandbox
<ekleog>
imo we should either remove all the things from the sandbox or add all stdenv because there's no reason to care more precisely :)
<samueldr>
I think it will break the initial bootstrap some... at least before we seed it with our own busybox sh binary
<samueldr>
(and will definitely break the nix pills)
<ekleog>
it'd definitely be a break-the-world change, but might be worth it… rfc fodder I guess
<samueldr>
I think what would be more practical is a way to opt in/out paths at the mkDerivation level
<samueldr>
since, fun fact, when you invoke the nix build the end-user *is* in control of those paths!
<samueldr>
ekleog: if you want to break expectations in your setup, a trusted user can use --option sandbox-paths "..."
<samueldr>
and that doesn't affect the drv hash
<samueldr>
a good/bad troll could start building derivations with /usr/bin/env present, and /bin/sh absent!
<gchristensen>
that is why i never mark my user trusted
<gchristensen>
I'm not smart enough to decide when itis okay to break purity
<samueldr>
I wonder why I'm trusting myself
<samueldr>
I mean, there must be a reason
<samueldr>
oh, `nix-copy-closure`
<ekleog>
oh interesting… unfortunately opting in/out of paths also means that builds will work only if sandbox is on, so we probably shouldn't make that too easy to use or it'd end up breaking darwin badly :/
<samueldr>
oh, I'm not saying it should be used... it **shouldn't** be used! that's a big footgun just laying there
<ekleog>
oh no I meant about your suggestion of <samueldr> I think what would be more practical is a way to opt in/out paths at the mkDerivation level
<ekleog>
or was it sarcastic?
* ekleog
claims poe's law
<samueldr>
no, totally genuine and honest, but make it part of the computed hash as inputs
<samueldr>
you want a /bin/sh in the sandbox? DECLARE IT
<ekleog>
oooh ok if we can restrict that to only /bin/sh and /usr/bin/env it'd make sense
<samueldr>
no need to restrict it... adding more sillyness to the sandbox would change the store path
<ekleog>
if we wanted to make that work for arbitrary executables it'd probably be bad for darwin portability as afaiu it doesn't have sandboxing
<samueldr>
making it pure again
<samueldr>
ah, I see what you mean
<ekleog>
otherwise would have been something I'd probably have been all in favor of :)
<samueldr>
then at that point it shouldn't be used, but I don't think restricting at the Nix level is needed... since (in my mind) it would be pure it'd be obvious if people start adding to it so it
<samueldr>
so it's not an issue*
<ekleog>
well it's a big footgun
<samueldr>
yes, but a pure footgun
<samueldr>
(but I see now that since the sandbox doesn't exist everywhere Nix exists it's a non-starter)
<ekleog>
oh ok just understood your last comment with the context “if we assume there's sandbox everywhere” :)
<ekleog>
sorry for my penultimate comment then ^^'
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
jonringer has quit [Ping timeout: 258 seconds]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
FRidh has joined #nixos-dev
<puck>
<samueldr> you want a /bin/sh in the sandbox? DECLARE IT <- i kinda wish you could bind mount custom store paths into the builder tbh
tomberek has quit [Ping timeout: 240 seconds]
<supersandro2000>
puck: you can with sandbox-paths
<puck>
supersandro2000: that's not what i meant
<puck>
supersandro2000: i can't just ask the user of my project to modify /etc/nix/nix.conf differently for every single drv, can i
<supersandro2000>
just add the option to nix-build
<supersandro2000>
might be that the user needs to be a trusted user
<puck>
again, i can't really ask the user to go "please run nix-build 70 times with these settings for each of these", and i don't want to require any special configuration
<puck>
the concept of trusted users breaks the entire reason nix exists
<supersandro2000>
there are things like makefile or shellscripts to run 70 commands
<supersandro2000>
no, it doesnt
<supersandro2000>
yeah, then try something different 🤷
<supersandro2000>
put the things you need into derivations and add them as depedency
<puck>
trusted users allow you to arbitrarily replace paths in the store, so on a nixos system you can just swap out the output that provides sudo/su/setuid
<puck>
supersandro2000: but how do i get them to show up in /usr/bin or wherever; the "store paths are in the nix store in the sandbox" is easy to do
<supersandro2000>
I can do the same if I have sudo
<supersandro2000>
patch the paths to not be absolute
pmy_ has quit [Ping timeout: 268 seconds]
<puck>
i do that sometimes but it's kind of a pain
<puck>
and then still, why does /bin/sh exist in the sandbox
pmy_ has joined #nixos-dev
tomberek has joined #nixos-dev
<supersandro2000>
either some bootstraping requires it or it is so often hardcoded at so many places that it is not easy to get rid of
<symphorien[m]>
because system() requires it, and it's mandated by posix
<puck>
symphorien[m]: so is env, and so is a whole slew of other binaries, but those aren't in the default sandbox either
<puck>
symphorien[m]: also
<puck>
> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):493:115
FRidh has quit [Quit: Konversation terminated!]
<puck>
supersandro2000: right, but we're already patching all the other bits, and the bootstrap explicitly downloads a statically linked busybox for shell usage
<supersandro2000>
'/usr/bin/env is also there
<symphorien[m]>
not in the sandbox I think
<puck>
stat: cannot statx '/usr/bin/env': No such file or directory
<das_j>
(for this vulnerability at least, there is another one)
<supersandro2000>
hexa-: did you get anywhere with the curl update and nix breaking? maybe we can try 7.75 + cve fixes?
evils has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 240 seconds]
AlwaysLivid has joined #nixos-dev
<hexa->
I tried to apply the patches on top of 7.74.0, which didn't work cleanly (20.09)
<hexa->
can try 7.75.0
<hexa->
meh, also doesn't apply cleanly, will take a look after work
<supersandro2000>
would have been to easy
<sphalerite>
Mic92: spacekookie: do you know if you'll be there for the RFC meeting today?
<Mic92>
sphalerite: Yes. I am there
kloenk has joined #nixos-dev
<LinuxHackerman>
Perfect, it worked :D
<kloenk>
hi
<devhell>
I'm trying to update `illum` in nixpkgs, so I've changed the version info, the rev, and the sha, and when I try to build it with nix-build -A illum, I get fatal: git cat-file: could not get object info, any ideas? I've never encountered this before.
<symphorien[m]>
perhaps the build system supposes that you build from a git checkout when the derivation uses fetchzip/fetchtarball which means there is not .git ?
<devhell>
symphorien[m]: nope, it's a git repo with a submodule, using fetchgit and fetchSubmodules = true;
<symphorien[m]>
add leaveDotGit = true
<devhell>
symphorien[m]: I'll try, thank you
<devhell>
symphorien[m]: nope, same error
<symphorien[m]>
did you change the hash ?
<devhell>
yes
<symphorien[m]>
no idea then, sorry
<devhell>
symphorien[m]: no problem, thanks anyway :)
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
devhell has quit [Ping timeout: 246 seconds]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
justanotheruser has quit [Ping timeout: 258 seconds]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<arianvp_>
hexa-: can I ask an ansible question?
<arianvp_>
I see you're also a nix user doomed with supporting ansible :P
<arianvp_>
have you found a reliable way to specify extra dependencies for ansible (like boto) for modules like aws_s3? I now am overridng ansible_python_interpreter in inventory... but it seems like there should be a better way
orivej has quit [Ping timeout: 265 seconds]
<hexa->
arianvp_: I hardly am an expert on the subject matter … and by now I started using ansible in a venv managed by a nix-shell/nix-direnv
<hexa->
last time I required support for something (netconf) I added ncclient to propagatedBuildInputs :<
<hexa->
I guess it would be okay to add many conditional inputs to support certain things, but the package is a bit undermaintained as it is, because the 2.10 update introduced a dependency pew pew
<hexa->
which supersandro2000 wanted to take a stab at
<hexa->
we already have "windowsSupport ? false"
orivej has joined #nixos-dev
jonringer has joined #nixos-dev
kraem has quit [Ping timeout: 240 seconds]
<arianvp_>
yeh the 2.10 release is super messy
<hexa->
we're also using mitogen, so no 2.10 for us anyway yet
<hexa->
ansible was chosen because we could also maintain network devices with it
<hexa->
so there is that
<domenkozar[m]>
I'm thinking we could use CODEOWNERS to allow people to merge things if they review it
<domenkozar[m]>
mainly for security, so you can't slip in yourself as a code owner
<domenkozar[m]>
I think this would save us handing out full commit access
<domenkozar[m]>
especially when most of the folks are interested in one part of nixpkgs
<sterni>
definitely!
<sterni>
Ideally we'd also be able to hand out codeowners for the directories of packages that are maintained by people
<sterni>
the file is going to be a bit noisy
<sterni>
but I'd be nice if ppl who have proven themselves could merge updates for stuff they maintain themselves
<sterni>
or merge auto bumps from nixpkgs-update etc
<tazjin>
is there a github plugin that works more like Gerrit owners? (i.e. you have owners definitions in the subtrees, rather than trying to maintain one humongous file)
<tazjin>
domenkozar[m]: conflicts, keeping the file clean etc. (see also: all-packages.nix)
jonringer has quit [Remote host closed the connection]
<domenkozar[m]>
that feels like microoptimization to me, by the current pace we get about 1 commit request per week
<domenkozar[m]>
and resolving such conflicts is quite quick
<tazjin>
we can get back to it in two years when the file is a mess ^^
jonringer has joined #nixos-dev
<domenkozar[m]>
yeah :)
<domenkozar[m]>
I'm sure it will happen, but if we try to take too much steps at the time, we might take none
<domenkozar[m]>
same time*
<tazjin>
I like looking at these things right away if they're known from experience to become issues, because doing it later is a whole migration project, but that's a learning exercise that will spread the experience :p
<gchristensen>
domenkozar[m]: I'm curious about your comment w.r.t. how codeowners will help a PR without a connected maintainer?
<domenkozar[m]>
it won't, but it will reduce friction if someone submits a PR and it gets no response, they can add themselves to be maintainer of that bit and thus easily join us without exposing too much risk
<domenkozar[m]>
so once we merge that, the next PR is easier
<domenkozar[m]>
it also solves the problem of not getting direct push access
<gchristensen>
I guess I'd like to see what the qualifications are to get merge access to a subsection / package, certainly a lighter weight process compared to a debian-like, but I would hope for something more than a one-off PR
<domenkozar[m]>
yeah that's the policy part I mentioned, we'd need to figure that out.
<domenkozar[m]>
but that question is the pandora's box of many other problems we have
<gchristensen>
definitely :)
<MichaelRaskin>
One-off is probably not enough, but depending on the area one non-trivial PR elsewhere and a couple in the are that nobody else works on (despite it having some FLOSS) might be enough
<domenkozar[m]>
So I got the order wrong: 1) who qualifies for commit access 2) a way to give commit access to certain parts of nixpkgs without direct commit access
<gchristensen>
MichaelRaskin: maybe part of that decision is the cost of a update (ie: # of impacted packages)
<domenkozar[m]>
I think I would like to follow linux kernel model there
<domenkozar[m]>
so you'd have hierarchy of maintainers
<domenkozar[m]>
so almost anyone can be like: here's how to package Kotlin in Nix and contribute that, then that would fall into the languages maintainers that could say if things go weird
<domenkozar[m]>
making the whole governance more explicit
<gchristensen>
probably good
<MichaelRaskin>
Explicit governance will take forever to converge
<MichaelRaskin>
Pretty sure there are simple cases that can be handled unanimously case-by-case though
<gchristensen>
yea
<MichaelRaskin>
I would say the impact should be weighted by popularity and build cost
<MichaelRaskin>
A bunch of cheap packages that nobody else wants to claim and that are not the load-bearing part of a system can have way lower requirements compared to the # of packages impact than, dunno, Nix or LibreOffice package (single package each, yeah)
Raito_Bezarius has quit [Ping timeout: 258 seconds]
<domenkozar[m]>
I would avoid NIH and take a look what communities managed to pull this off
<domenkozar[m]>
and lessons learned, etc
<supersandro2000>
hexa-: did I? I must admit I forgot that..
<supersandro2000>
Do we currently have code owners who do not have fun commit access? If not we don't need to review the codeowners file
<MichaelRaskin>
domenkozar: there is a problem that most of the communities who have pulled this off, had a pretty different situation. Like value coherence
<MichaelRaskin>
(for most of the users most of Nixpkgs — different «most» for each person, though — is absolutely useless)
<domenkozar[m]>
I don't think we're that much special
<supersandro2000>
I don't think it is feasible to give people merge access for single packages. This just ends in micro management. Parts like ocaml, python, ruby, whatever is fine for me if the person proved to be knowledgeable and writes good code
<supersandro2000>
Also it would need to be blocked if to many packages update or stdenv is rebuild
<sterni>
on the contrary, I'd argue that this would give some meaning to being a maintainer again :p
<domenkozar[m]>
well I realize there are lots of questions to be resolved, but think of it as a migration from global commit access to localized commit access
<domenkozar[m]>
so most of the problems stay as there were
<MichaelRaskin>
Hmm, counting by packages makes mega-dumps like cargo2nix easier to maintain than Python packages style things
<domenkozar[m]>
(not that we shouldn't solve them, but not all at the same time)
<MichaelRaskin>
One incentive I would not want to create…
<gchristensen>
domenkozar[m]: yup I'm definitely on board with that
<supersandro2000>
also I don't want to follow up every other self merged PR because there are obvious no nos in them
<domenkozar[m]>
gchristensen: :)
<MichaelRaskin>
Note that if you want things not to stall badly, you still need pretty wide base of people who can accept new stuff
<gchristensen>
yeah
<domenkozar[m]>
MichaelRaskin: the incentive would then be to group packages by folder by the herd
<domenkozar[m]>
which I think is better than the current random
<domenkozar[m]>
I'm quite confident that this would expand our write access
<domenkozar[m]>
so it can only be better, not worse
Raito_Bezarius has joined #nixos-dev
<supersandro2000>
if we want to group packages then we would want to auto sort them, right?
AlwaysLivid has quit [Ping timeout: 240 seconds]
<gchristensen>
I'm not sure there is a reasonable taxonomy we can apply
<MichaelRaskin>
domenkozar[m]: re: grouping — supersandro2000 said «number of packages», and I happen to know that's exactly what's meant (but not what should be adopted verbatim)
<MichaelRaskin>
supersandro2000: why?
<MichaelRaskin>
domenkozar[m]: I agree that we need to remove the global-commit bottleneck, but some people actually want the migration-from interpretation (which will end badly)
<supersandro2000>
if some package rebuilds 5000+ I think that should be treated special
<MichaelRaskin>
5000 is a number
<domenkozar[m]>
we could make the merge block until a label is set
<MichaelRaskin>
I mean, it depends on the kind of the packages
<domenkozar[m]>
so things can be merged only once ofborg sets it
<supersandro2000>
I think we should start with easy updates and packages which are not very important for nixpkgs and see how it goes
<gchristensen>
that sounds good
<supersandro2000>
if it goes well we can expand from there
<supersandro2000>
and the risk to break something for everyone would be smaller
<MichaelRaskin>
supersandro2000: objection, if it goes not well but better than now, we still want to expand it
<domenkozar[m]>
well it should start with an RFC
<domenkozar[m]>
that would have a gradual transition
<domenkozar[m]>
lots of work with the logistics
<MichaelRaskin>
You might be underestimating the problems of agreeing on a large-scope policy, or overestimating the problems of getting agreement on a limited-scope policy with further work «to be done based on the experience we gain»
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
<domenkozar[m]>
I don't underestimate it, but I know that it can be worked out by ignoring cynics and taking good feedback into the account :)
<domenkozar[m]>
good feedback == actionable
<domenkozar[m]>
I know it can be because it has been done :)
<MichaelRaskin>
Idealists will give a ton of actionable change proposals, but will they be compatible
<supersandro2000>
What are we doing if we see abuse?
<supersandro2000>
For example people merge changes with low code quality or mistakes which are not catched by CI?
<sterni>
that is surely something to be addressed in the RFC
<sterni>
but I don't see why you are being so pessimistic about this
<ekleog>
I just heard a summary and did not read all the backlog, but FWIW, any policy to give maintainers limited commit rights should consider the fact that the current maintainer list is free-for-all (I've already merged PRs that bumped a version + added someone maintainer), and there can be malicious maintainers that would want to add backdoors
<MichaelRaskin>
supersandro2000: the same as now?
<supersandro2000>
sterni: I like the idea but we should think about what could go south and how to prevent it
<sterni>
the whole what if there is abuse is arguing in bad faith imo as this is an issue that already exists theoretically, but in practice most things you could consider abuse just have been honest mistakes
<ekleog>
so long as all abuse is just honest mistakes, it means that our security policy works :)
<sterni>
isn't the security policy just more or less give ppl commit access who seem trustworthy to a few people
<supersandro2000>
sterni: well there are some people who really get vocal if some detail about their setup fails to eval
<ekleog>
FWIW, IMO the marvin approach of “maintainers can just r+ and then a committer just has to sanity-check for backdoors and click “merge”” is optimal in that committers ensure security and maintainers ensure all the rest
<supersandro2000>
and there are enough people who would ignore review feedback and just merge to be on the fast route
<ekleog>
sterni: it is, and it requires more effort to insert a backdoor than the current “did a hash-bump update to some well-used but not well-maintained library once five years ago”
<MichaelRaskin>
Some of the feedback is fine to ignore
<MichaelRaskin>
(like formatting — we either have written down rules, have nixpkgs-fmt officially recognised, or stop pretending)
<sterni>
supersandro2000: well if feedback is s/[ maintainers.foo ]/ with maintainers; [ foo ]/ :p
<supersandro2000>
sterni: I stopped caring about that if its the only thing
<MichaelRaskin>
sterni: the policy is more «who has sunk unreasonably much work into Nixpkgs»
<sterni>
:D
<supersandro2000>
can we just make nixpkgs-fmt the standard formatter?
<ekleog>
rfc fodder
<ekleog>
(hope yes)
<supersandro2000>
then I could just guide people to that and be done
<MichaelRaskin>
No.
<MichaelRaskin>
Then we could add it to editor-config
<MichaelRaskin>
(all changed files should be fixpoints of nixpkgs-fmt)
<sterni>
afaik zimbatm[m] is still looking for feedback on nixpkgs-fmt
<ma27[m]>
one reason why I dislike formatters (especially aggressive ones) is that it gets harder to `git blame` a file. If I'm confused about why something is the way it is, I want to find the last commit directly to understand the why.
<sterni>
and we probably should check for edge cases where nixpkgs-fmt does the wrong thing
<sterni>
ma27[m]: nixpkgs-fmt has been written with the goal of reducing diff sizes and preventing merge conflicts in mind
<supersandro2000>
sterni: he fixed the adding space things adding bug and I am not aware of any other bugs
<ekleog>
ma27[m]: well, one policy may be “all newly changed files should be formatted”, not necessarily “we ought to do a treewide change to format all the things”
<sterni>
ma27[m]: if we do a global reformat we could add a ignore for git blame as it can ignore specific revisions when calculating blames
<ekleog>
which would reduce the issue
<supersandro2000>
unlike nixfmt which adds line breaks all over the place
<MichaelRaskin>
ma27[m]: if a single formatter is adopted and it is not as horrible as black re: trigger-happy line length handling, then it should be a one-time damage, and not the first one…
<ma27[m]>
ekleog: ok, that's sounds ok to me though :)
<supersandro2000>
sterni: that only works on the client but yeah that should be done
<sterni>
supersandro2000: I'm thinking more about some domain specific uses where the formatting is just annoying
<supersandro2000>
MichaelRaskin: just set black to 250 line length or so
<MichaelRaskin>
supersandro2000: tell it to flokli
<sterni>
since disabling black doesn't seem to reach consensus I guess I'll try to disable the line length check
<sterni>
because it is the most obnoxious by far
<supersandro2000>
ma27[m]: I also pushed the bundix update to 20.09 which adds the final new line
<ma27[m]>
nice, thanks! :)
<MichaelRaskin>
I think black is very bad at configurability and mistakenly assumes that's a feature
<gchristensen>
such a nice feature
<supersandro2000>
if it wouldn't do so many line breaks to reduce line lengths by 4 it wouldn't be that bad
<supersandro2000>
but adding 4 new lines to save 2 line length is just rediculous
<gchristensen>
we probably need github to support blame's ignore-rev-file before we go mandating a formatter
<MichaelRaskin>
Isn't blame a complicated enough operation to not care what GitHub does?
<MichaelRaskin>
Like, if it can be configured, good, if not, oh well
<gchristensen>
I don't think so, no, I find github's blame view to be more useful that `git blame` on its own from time to time
<supersandro2000>
Requiring it for new packages shouldn't cause harm
<supersandro2000>
and for bigger reworks it is also not a bad idea
<gchristensen>
it does actually
<supersandro2000>
if you change every other line already you can also format it
<gchristensen>
because you have a patchwork of rules of formatting and a given PR could touch files that must be formatted and files that should not be automatically formatted
<supersandro2000>
also githubs blame is laggy af
<gchristensen>
if we're going autoformatted, imo, we should do it in service of making the contributor experience first priority
<supersandro2000>
ehm yeah? maybe we shouldn't enforce it with an action yet
<supersandro2000>
but for new files it would be a good idea
<gchristensen>
unchecked autoformatting isn't very useful
<MichaelRaskin>
Is there _any_ git hosting that supports configurable blame?
<supersandro2000>
why? we are requiring it in X, please start doing it anyway
<sterni>
lol if you set black's max line length to a negative value it does its very best to reach that target
<gchristensen>
a shame they made it configurable
<sterni>
a shame they didn't make it possible to disable it altogteher
<ekleog>
I mean having nixpkgs-fmt in the editorconfig without any hard requirement would probably already be a good thing, next step is a check that all modified files are properly formatted, and last step is optionally a treewide change imo?
<ekleog>
(assuming nixpkgs-fmt is ready for prime time that is)
<gchristensen>
last time we had an autoformatter in Nixpkgs but not mandated on every PR it was deleted because people were afraid of all the changes it would introduce after testing their little contribution
<ekleog>
oh :( hadn't followed that, so it burns down the idea of “require autoformatter only on modified files” i guess
<ekleog>
thank you for the piece of history :)
<gchristensen>
yeah, it is unfortunate :(
<ekleog>
hmm so I've just checked the github webui, and there's the small “view blame prior to this change” button — would that not be enough of something to say “ok we can have a mass-reformat commit and people will have one more click to do when blaming”?
cole-h has joined #nixos-dev
<supersandro2000>
we have another troll in #nixos : BitchardGnollman