<zybell_>
Question : From traffic on IRC I got the impression that plugins are the weak point of nix. Would it be a good idea to mandate every extensible package to provide a .nix, which can be used by plugin packages to announce theirself.
<zybell_>
?
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
pie_ has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<simpson>
zybell_: Do you have code that you'd like to share?
pie_ has quit [Ping timeout: 260 seconds]
page_ is now known as page
<zybell_>
no:I do not even have an idea how to implement that.Vague direction:make a dir in /var named after the hash,import all .nix in there add derivations to a list?
<simpson>
I've gotten the impression that you don't use Nix. :c
<zybell_>
Plugins would have to place a symlink(?)to their .nix in there. But how to achieve that? Kind of profile?
<simpson>
Don't we already do that sort of thing? What, precisely, do you plan to fix? Or do you just have a vague feeling that plugins don't work in Nix?
<zybell_>
They work,after a fashion,but they are brittle.
<zybell_>
Every language needs special tools for this,because every language implements them other way.
<zybell_>
pkg-config the shell-'plugin' designed to help gcc find its compiler-'plugin's (headers and librarys) isnt used even by C packages. Sometimes even that breaks.
<zybell_>
To use pkg-config for instance for perl-modules (this morning:Cant find Git.pm) it would have to be extended.
<simpson>
So the reason we need to overhaul plugins is because pkgconfig can't find Perl modules that it wasn't designed to find?
<simpson>
Sorry, maybe that's too pointed. But it's not impossible to add `perlPackages.GitPurePerl` to `buildInputs`, is it?
<zybell_>
You did misunderstand:pkg-config with a minimal extension could be a possible *solution* to the problem. Git.pm wasnt found by some *nix*-command that needed it to run,making recovery difficult
<simpson>
I can't imagine any such minimal extension, but I'm happy to look at your design doc.
<zybell_>
But I would like a *fundamental* solution in nix, because linux is on many levels plugin based,if you look right at it.
<simpson>
Looking right at it, Linux exposes a stable syscall API. Again, not seeing it. The kernel's 'plugins' are not fully dynamic, but must be prepared according to the current kernel version's private internal ABI.
<zybell_>
The minimal extension would be a keyword 'key'(or whatever)that would enable in all .pc that *depend* on a .pc that contains it, a keyword,given as argument,that can be used like the headers and libs now.
<zybell_>
All plugins *depend* on a common interface with the loader. If that changes, the plugin breaks.
<zybell_>
And I didnt mean the kernel only. By making a file executable you 'extend' the language of the command line. *For instance*
<ekleog>
Would you mind writing down a more detailed example of what you mean (with an example of plugin definition and plugin acceptation definition) and open it either as an issue on nixpkgs or as a PR on rfcs? At least I don't really get what you mean, and don't feel like IRC is the best medium for conveying ideas
<simpson>
zybell_: I really would enjoy reading your design doc. But now is the time when I play video games. Peace.
<zybell_>
Ive gotta go too . AFK
<gchristensen>
let's all just go play video games with simpson
<zimbatm>
if they don't want to provide the hosting anymore, or more likely ask for a lot of money we can get a data dump and host it ourselves
<zimbatm>
discourse is open-source
jtojnar has quit [Quit: jtojnar]
<Mic92>
zimbatm: the question was, if they data migration so that we export accounts from their instances to ours.
<Mic92>
*provide
<Mic92>
How about making a short survey on the current mailing list for this topic? I am personnally not a frequent reader.
<zimbatm>
I don't know if we'll get the password hashes in the data dump
<zimbatm>
we could make the github auth mandatory
<zimbatm>
yeah that's planned next
<zimbatm>
first I wanted to find a few interested people to setup the site properly
<samueldr>
self-hosted discourse has a couple customization knobs available e.g. it was possible to add custom HTML and CSS to add a common site header on top of the discourse UI
<samueldr>
well, had, a couple years ago
pie_ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
xeji_ has joined #nixos-dev
xeji__ has joined #nixos-dev
xeji has quit [Ping timeout: 264 seconds]
xeji_ has quit [Ping timeout: 264 seconds]
xeji__ has quit [Quit: WeeChat 2.0]
ma27 has quit [Ping timeout: 265 seconds]
ma27 has joined #nixos-dev
ckauhaus has quit [Quit: Leaving.]
Lisanna has joined #nixos-dev
ma27 has quit [Ping timeout: 265 seconds]
MichaelRaskin has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
taktoa has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
Sonarpulse has joined #nixos-dev
<domenkozar>
wait, NIX_REMOTE doesn't specify if Nix is using daemon or not
<domenkozar>
so what's the way to detect that now?
<domenkozar>
pgrep nix-daemon?
<Mic92>
domenkozar: in that case the manpages would be out of date
<LnL>
domenkozar: test -w /nix/var/nix/db
<domenkozar>
LnL: :thumbsup:
genesis has quit [Read error: Connection reset by peer]
<samueldr>
hi!, I know someone looked at my PR and asked for a review by niksnut, but him being away and this bug being annoying (especially) for new users, could it be verified by someone else? (I do understand though that the particular code is managed by niksnut) https://github.com/NixOS/nixpkgs/pull/39342
<samueldr>
would it be anything else I would be fine with simply waiting :/ sorry for being a bit pushy there
<sphalerite>
samueldr: hah, pushy.
* sphalerite
appreciates puns. Especially unintentional ones.
<samueldr>
thanks MichaelRaskin!
<samueldr>
may I assume you're handling the cherry-pick too?
<MichaelRaskin>
Ah right, there are these annoying stable branches
<samueldr>
only one though
<MichaelRaskin>
Well, in general two, but the older one doesn't have the problem in question
<ekleog>
hmm, 17.09 is EOL for ~3 weeks, isn't it?
<samueldr>
I was under the impression 17.09 wouldn't really be updated
<MichaelRaskin>
I would say that 17.09 is EOL in at least 1 week in the future
MichaelRaskin has quit [Ping timeout: 248 seconds]