gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 is released! https://discourse.nixos.org/t/nixos-19-09-release/4306 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
drakonis has joined #nixos-dev
ris has quit [Ping timeout: 240 seconds]
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-dev
tdeo has quit [Changing host]
tdeo has joined #nixos-dev
lovesegfault has quit [Ping timeout: 265 seconds]
justanotheruser has quit [Ping timeout: 248 seconds]
ivan has quit [Quit: lp0 on fire]
harrow has quit [Quit: Leaving]
Scriptkiddi has quit [Remote host closed the connection]
das_j has quit [Remote host closed the connection]
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
pxc has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
harrow has joined #nixos-dev
andi- has quit [Ping timeout: 260 seconds]
ivan has joined #nixos-dev
justanotheruser has joined #nixos-dev
justanotheruser has quit [Read error: Connection reset by peer]
andi- has joined #nixos-dev
justanotheruser has joined #nixos-dev
<ryantm> Is pkgsStatic expected to work on Darwin? https://github.com/NixOS/nixpkgs/pull/77180
<{^_^}> #77180 (by anmonteiro, 2 days ago, open): libev: Add statically linked libev to pkgsStatic
<drakonis> the submission period opens in around 4 days
<drakonis> please dont forget to do it this time, its the nth time nix does not participate due to some organizational factor
ivan is now known as ivan
drakonis has quit [Quit: WeeChat 2.6]
justanotheruser has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-dev
lovesegfault has joined #nixos-dev
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ has joined #nixos-dev
tilpner has joined #nixos-dev
tilpner_ has quit [Ping timeout: 258 seconds]
Jackneill has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7]
<domenkozar[m]> it's not that we forgot
<domenkozar[m]> but that it's quite some work :)
<domenkozar[m]> I'm looking for someone to spend time with me to set things up
<clever> ryantm: i dont think apple supports fully static binaries, ever
<LnL> yeah, go tried that with syscall wrappers but that completely broke with a kernel update from apple
<LnL> and even that might not have been completely static
<Profpatsch> I hear drakonis has volunteered for summerofcode setup -.-
<domenkozar[m]> drakonis: are you a student?
<Profpatsch> domenkozar[m]: He parted four minutes after writing as far as I can see
<Profpatsch> s/he/they/
FRidh has joined #nixos-dev
zarel has quit [Ping timeout: 258 seconds]
zarel has joined #nixos-dev
<domenkozar[m]> oh well :)
<FRidh> maybe mention gcc9 has landed in nixpkgs? https://github.com/NixOS/nixpkgs/pull/68029
<{^_^}> #68029 (by globin, 18 weeks ago, merged): Default gcc to gcc9
<FRidh> as in, default
<makefu> domenkozar[m]: the closing quotation marks should be before the - Aesop
<domenkozar[m]> right, that's tricky to fix
<domenkozar[m]> maybe another day :)
<domenkozar[m]> alright I guess that will do
<domenkozar[m]> FRidh: sorry, not accepting new entries during the publishing process :)
<domenkozar[m]> you can add it to the new CFP
<arianvp> domenkozar[m]: just did a proofread. looks fine to me
<arianvp> The python az package, has been added. Replacing the deprecated node azure package. < Comma instead of period
<arianvp> or "This replaces the deprecated node azure package"
<arianvp> ah
<arianvp> :'D
<domenkozar[m]> but thanks :)
misuzu has quit [Quit: leaving]
misuzu has joined #nixos-dev
<Profpatsch> domenkozar[m]: thanks for doing the weeklys with such regularity btw.
<Profpatsch> domenkozar[m]++
<{^_^}> domenkozar[m]'s karma got increased to 8
<domenkozar[m]> oh well, could be better :)
Synthetica has joined #nixos-dev
__monty__ has joined #nixos-dev
kenjis has joined #nixos-dev
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
<jtojnar> Is it possible to register on Hydra? I previously used Google account but it no longer signs me in (probably some privacy blocker)
<LnL> hydra supports local accounts, but everybody has a gmail login AFAIK
<gchristensen> I think if you disable the privacy blocker, log in, and then enable it again -- it'll work
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 240 seconds]
zarel has quit [Quit: ZNC 1.7.4 - https://znc.in]
zarel has joined #nixos-dev
janneke_ has joined #nixos-dev
janneke has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
<gchristensen> gnustep.base is failing in hydra because its C compiler is apparently not working
FRidh has quit [Quit: Konversation terminated!]
<Taneb> gchristensen: "checking for gcc... clang" seems odd to me
<gchristensen> indeed
drakonis has joined #nixos-dev
<gchristensen> Taneb: are you available to take a look-see?
<Taneb> I can take a brief look
<drakonis> domenkozar[m]: yes i'm a student, it was quite late by the time i sent out that message
<drakonis> i can participate
<domenkozar[m]> that's great :)
<domenkozar[m]> what are you interested in?
<drakonis> if we go by gsoc's rules, a counter question would be better, what can be mentored?
<drakonis> and what work is needed right now?
<gchristensen> I had specifically blocked off my calendar to add testing NixOS/nix to ofborg today, and just like always my calendar has filled up in spite of my blocking off :|
<domenkozar[m]> sounds like you need a calendar where blocking off works
<gchristensen> lol
<drakonis> i'm interested in programming i suppose
<drakonis> vague arent we
<drakonis> but if there's participation in gsoc, it'll probably need feature projects and not packaging things
<gchristensen> +1
<gchristensen> packaging isn't such an interesting, larger-scale project anyway
<drakonis> packaging is a minor concern because there's enough people doing that on a daily basis these days
<gchristensen> (although something like "packaging all of the Rust ecosystem automatically"...)
<drakonis> that'd be good
<domenkozar[m]> it's often easier to propose a project and find a mentor
<domenkozar[m]> if you're interested into something that's closer to your passion
<domenkozar[m]> opportunities are endless
<drakonis> of course
<drakonis> don't you need a list of projects to actually sign up for gsoc in the first place?
<domenkozar[m]> yes, that's how we'd get one :)
<drakonis> hmmm, let's see
<drakonis> proposal number 1: init service config generators
<drakonis> that allows for supporting s6 and other inits for services
jared-w has joined #nixos-dev
<drakonis> proposal number 2: enhance package definitions to include metadata for discoverability
<drakonis> should vastly improve package organization and abstract away the need for the current repository structure as a sideeffect
<drakonis> ie: find all packages that are a specific language and are libraries
<gchristensen> loving that one
<drakonis> proposal number 3: enhance package definitions to make it easier to include build options
<drakonis> there's various packages with hardcoded build features that could be moved into tweakable options, defaults remain the same however
<aanderse> proposal number 4: a web application abstraction that allows you to pick diffirent backends for serving web apps? :)
<drakonis> sounds good to me
<aanderse> me too
<drakonis> proposal number 5: allow packages that have dependencies akin to moving parts
<drakonis> ie: java packages that have multiple variants
<drakonis> there's three jdk types
<drakonis> being able to choose which one you would like to use on your package when building
<drakonis> ties up onto proposal 3 and 4
<drakonis> as does 3 with 2
<qyliss> making modules for web services is a nightmare
<qyliss> although worth noting somebody tried to add this before and it was rejected
<aanderse> qyliss: absolutely
<gchristensen> super abstract things like that don't tickle me much :(
<qyliss> gchristensen: we're missing out on lots and lots of web services because there's no consensus on how to do it
<qyliss> e.g. all the bikeshedding in the Mastodon PR that eventually made the author give up after months
<aanderse> well there you go drakonis ... you can work on web services, but you probably have to tickle gchristensen ;-)
<aanderse> lol
<gchristensen> yeah I know
<qyliss> we go through the same arguments every time because there's no standard way to do it, and it doesn't map all that well to the NixOS model
<gchristensen> but there is probably just not an abstract interface that can generically represent all the finesse many web applications require
<aanderse> yeah i haven't thought about it enough
<aanderse> maybe each web service just needs author(s) to write n backends
<gchristensen> I think providing a way to do that would prove more successful
<qyliss> One thing that would be an immediate improvement would just be a shared abstraction over Nginx and Apache to delegate certain path prefixes to other ports/sockets
<aanderse> qyliss: working on it... but having issues :(
<qyliss> oh? :(
<aanderse> well, not working on it to the extent you're saying
<adisbladis> I also wouldn't mind it if the module system was _mostly_ generic
<drakonis> now for proposals 6 and 7
<aanderse> but working on shrinking the gap between the awesomeness of the nginx and httpd services
<{^_^}> aanderse's karma got increased to 15
<aanderse> in master httpd can now do automatic letsencrypt stuff
<aanderse> that was a victory
<qyliss> nice!
<drakonis> implement guix's grafting and move defining nix the package manager options to being written in nix
<aanderse> implementing the locations option in httpd is easy enough... but not complete
<drakonis> and i suppose that's all i have for now
<Profpatsch> qyliss: I’m with gchristensen on this one, it looks to me like the problem with web services is usually that they have a quite complex setup.
<aanderse> without a corresponding directories option adding locations is probably a really bad idea
<Profpatsch> So I don’t see a good way to unify stuff there
<aanderse> Profpatsch: i don't see a good way (yet?) either, which is why i haven't tried to implement it
<drakonis> aanderse: haw, the things i listed out are probably year long projects
<aanderse> i haven't really thought about it enough yet, though
<qyliss> Profpatsch: almost every web service just wants a delegated path given to it by a web server
<aanderse> Profpatsch: but smarter people than i have thought about it... so yeah, one can always dream :)
<Profpatsch> drakonis: Yeah, you want something small in scope and then do 10% of what you want to do. :)
<drakonis> and they'll incur sweeping changes on the tree if successful
<qyliss> that's all I'm proposing implementing.
<Profpatsch> qyliss: So basically a generic way to proxyPass?
<drakonis> proposal 2 is great for hydra
janneke_ is now known as janneke
<drakonis> you can build things based on their metadata
<qyliss> Profpatsch: yes
<Profpatsch> drakonis: You could work on ofborg with gchristensen or ryantm’s bot
<qyliss> So that web service modules can set it (and more importantly know it) themselves, rather than having to be told it when it's already set in web server configuration.
<drakonis> that also works, yes.
<aanderse> qyliss: not quite there, but at least in the right direction... adding proxyPass to httpd: https://github.com/NixOS/nixpkgs/pull/76583/files#diff-e468c787a461c12f4586a188e3ddd5e0R8
<Taneb> gchristensen: for gnustep.base, I did a bisect and 8f729c0070ec3f78edadeaebcbd110257fe4577e is the offending commit ("gcc: switch default to gcc9")
<aanderse> WIP
<Taneb> Which is not very illuminating
<gchristensen> Taneb: hehe
<drakonis> worth a shot.
<drakonis> gchristensen: you down for this?
drakonis has quit [Quit: WeeChat 2.6]
kenjis has quit [Remote host closed the connection]
<jared-w> gchristensen: aanderse: qyliss: w.r.t. "standard APIs" for web services, it might be worth looking into kubernetes for API inspiration. It's the closest thing to a truly standard way to specificy "how a thing runs" that modern/trendy ops has at the moment. Their concept/api for an Ingress would be particularly relevant for abstracting nginx/apache/etc
<gchristensen> the ingress isn't really the thing, its like all the various tunables like "mount this directory at /foo unless it ends in .php in which case send it to php-fpm, unless it ends with .aspx in which case send it to the gunicorn worker for Python, and PPOPFIND requests to /meh/* get reverse proxied to 10.10.2.10"
<gchristensen> Ingress does cover a good bit of this
<gchristensen> dunno :/ maybe that would be sufficient
<adisbladis> gchristensen: Does our new supposed generic webapp abstraction have to cover everything?
<jared-w> yeah for all of that sorta nonsense you really have to end up just sticking your own proxy/server behind the ingress
<gchristensen> fair enough
<gchristensen> for web applications perhaps it would be sufficient, I am super skeptical about it for something like an init I guess
<jared-w> Otherwise you end up either forcing everyone to write their routing in a different DSL, use the same web server, or not have customized routing. It's just ugly and always breaks down somewhere in my experience.
<gchristensen> +1
<gchristensen> jared-w++
<{^_^}> jared-w's karma got increased to 2
<Profpatsch> tazjin: where do I find the lib-function-docs.nix file? Is it generated?
<Profpatsch> Is there docs for the doc generation? ;)
<tazjin> it's generated
<tazjin> that thing still works but should probably be modernised
<tazjin> it was basically a NixCon hack
<tazjin> but I'd like to wait until the docs RFC moves forward to see what happens
<Profpatsch> kk
<jared-w> Rewrite it in... oh, it's already rust, nvm
<Profpatsch> Ah, I found it in ../doc-support
<Profpatsch> jared-w: gotcha!
<Profpatsch> The only moral language
<jared-w> > mfw perl isn't mentioned as a moral language
<{^_^}> undefined variable 'mfw' at (string):273:1
<tazjin> lmao
justanotheruser has quit [Ping timeout: 258 seconds]
<Profpatsch> Doc generation is fun, because we have a full GHC stack and a full gcc stack and a full rust stack to build the docs!
<tazjin> > nix :3
<{^_^}> <LAMBDA>
<Profpatsch> tazjin: My emacs file cache was confused about where this file should be.
<Profpatsch> <LAMBDA>
justanotheruser has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
<Profpatsch> tazjin: this one’s for you https://github.com/a-schaefers/systemE
<tazjin> Profpatsch: yep, puck pointed me at it yesterday - imagine if emacs was literally the only process between the kernel and my browser
<tazjin> it'd be epic
<tazjin> terrifying, but epic
<Profpatsch> lisp machines are back!
<tazjin> > [ (a: []) ", the ultimate opcode" ]
<{^_^}> [ <CODE> ", the ultimate opcode" ]
<tazjin> >:0
<Profpatsch> Now, to replace that pesky kernel …
<tazjin> > (nix :3)
<{^_^}> <LAMBDA>
<tazjin> grr
<tazjin> Profpatsch: yeah, WIP - https://mezzanos.herokuapp.com/
<cransom> heh. nearly every link on that page is a todo
<Profpatsch> tazjin: Hm, I added the lib/customization.nix file to both the xml and the nixdoc invocation, but it doesn’t appear in the output
<tazjin> one minute, please hold the line
<tazjin> hmm
<Profpatsch> tazjin: It looks like this calls nix inside of nix to create the generated output
<tazjin> huh
<tazjin> Profpatsch: so I did this:
<tazjin> and it works
<tazjin> for some reason, if you flip the last two includes in the XML, docbook breaks
<tazjin> but if you put it before the options then it's fine
<tazjin> (??)
<tazjin> based on, uh
<Profpatsch> tazjin: Ah, blubb, do I need to run the makefile instead of nix-build the doc dir?
<tazjin> I did a nix-build in doc/
<tazjin> ah!
<tazjin> you need to make clean before doing that
<tazjin> (I think)
<Profpatsch> tazjin: Aah, duh, I wrote customisation.nix instead of customisation.xml …
<tazjin> :D
<Profpatsch> And of course the xml generator silently accepts missing imports
<Profpatsch> what did I expect :P
<tazjin> :]
drakonis has joined #nixos-dev
<Profpatsch> No, can’t get it to work.
<tazjin> try a clean checkout of nixpkgs, there might be some gitignored stateful stuff that gets included in a build if you ever did one in nix-shell
<Profpatsch> uhh, of course
<Profpatsch> tazjin: yeah, it works if I run make in a nix shell
<tazjin> Profpatsch: second last paragraph in this comment - https://github.com/NixOS/rfcs/pull/64#issuecomment-571693013
<gchristensen> /!\ Firefox users: it is super important to upgrade to Firefox 72.0.1, which is available on nixos-unstable-small, nixos-19.09-small, and nixos-19.09. other channels are likely vulnerable. /!\ more: https://www.us-cert.gov/ncas/current-activity/2020/01/08/mozilla-patches-critical-vulnerability
<Profpatsch> tazjin: thanks, added to talk queue
<gchristensen> if I had my way, allow-unsafe-native-code-during-evaluation could only be set via a flag passed at execution time :P
phreedom_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
phreedom has quit [Ping timeout: 240 seconds]
<infinisil> It could be safeish by only allowing a list of files declared in nix.conf to use builtins.exec
<gchristensen> yeah, shlevy wrote a plugin for something like that
<infinisil> Oh nice
drakonis has joined #nixos-dev
<FireFly> gchristensen: thanks for the heads-up
ris has joined #nixos-dev
<Profpatsch> Ericson2314: The PML article you link on the documentation rfc is very funny, because that’s nearly exactly the thing I designed as syntax for a structured markup format.
<Ericson2314> Profpatsch: oh wow!
<Profpatsch> (par this is a paragraph with some (b bold text))
<Profpatsch> (a this is a link { href=https://abc })
<__monty__> Profpatsch: Sounds like Scribble.
<Profpatsch> The only special symbols that have to be escaped are ({[]})
<Profpatsch> and \ of course
<Ericson2314> i would imagine yours and theirs is vageuly latex inspired?
<Ericson2314> Racket's scribble has some latex-style stuff too
<Profpatsch> Ericson2314: On so far as that you don’t have to quote strings. And there is no mapping to semantics yet.
<Profpatsch> Apart from that the first element in () is always semantically special.
<Profpatsch> And () are the only nesting structural element.
<__monty__> Have you looked at scribble? It really sounds like you're describing a lispy formatting DSL.
<drakonis> looks like you wrote a lisp
<Profpatsch> __monty__: That’s just a reader for racket which transforms @foo{ bar baz } to (foo "bar" "baz")
<__monty__> (foo "bar baz" I think?
<__monty__> Forgot the closing paren.
<__monty__> When lispers step away from s-expressions I expect there's a good reason : >
<Profpatsch> __monty__: looking at https://docs.racket-lang.org/scribble/reader.html it’s already horribly complex just because they are embedding it in a turing complete language
<Profpatsch> With lots of quoting and unquoting going on.
<Profpatsch> A good markup language is anything but turing complete if you ask me :)
<drakonis> embed programs in your documentation :V
<Profpatsch> Plus it has (at least) two layers, one for the syntax and one for the semantics of markup elements.
<Profpatsch> Ericson2314: Incidentally, I have no idea how this is parsed: https://github.com/practical-markup-language/user-manual/blob/master/text/03_quick_start.pml#L17
<Profpatsch> Because no quoting makes it highly ambiguous without backtracking.
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 265 seconds]
drakonis has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
<Ericson2314> Profpatsch: yeah I am less enthuastic about what their solution than their description of the problem
<Ericson2314> I am not even sure it's impleemnted
<Ericson2314> let alone is the implementation not a pile of garbage
phreedom has joined #nixos-dev
phreedom_ has quit [Ping timeout: 240 seconds]
<niksnut> that looks a lot like my markup language
<Profpatsch> lol
<niksnut> which has a pretty short grammar: https://github.com/edolstra/sst/blob/master/hs/Parser.hs
<Profpatsch> looks like everybody is converging
<Profpatsch> niksnut: what’s begin and end?
<niksnut> it's the \begin{foo} ... \end{foo} syntax as in latex
<niksnut> to be precies, \begin{foo} BLA \end{foo} is equivalent to \foo{BLA}
<niksnut> but useful for large elements (like chapters/sections)
<niksnut> where \end{foo} is more informative and gives better error messages than }
<niksnut> btw it also has a trivial macro facility: https://github.com/edolstra/sst/blob/master/hs/Eval.hs
<niksnut> trying to avoid turing completeness...
<niksnut> but no schema language
<Profpatsch> Oh no macros
<niksnut> yeah it's potentially a dangerous thing to have, so I'm not married to it
<niksnut> I just pasted an example into pastebin, which triggered their spam filter...
<niksnut> latex == spam
<drakonis> by the way, i have to bring up google's season of documentation as something to sign up for
<Profpatsch> nice. However, I’m not a fan of begin and end block, because you lose support of your editor. Balanced parens are a good thing
<drakonis> is a nix book considered technical documentation?
<niksnut> it gets all this free editor support
<Profpatsch> I raise you paredit :)
<niksnut> drakonis: yes, definitely
<drakonis> good, because you can get money from google to pay someone to write that
<drakonis> it opens in march
<drakonis> after 2019's cycle ends in the first week of march this year
<niksnut> I vaguely remember that somebody tried last year
<niksnut> or maybe just had the intent
<drakonis> nix book came up in nixcon's docs meeting i think
neeasade has quit [Ping timeout: 252 seconds]
lovesegfault has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
ixxie has joined #nixos-dev
drakonis has joined #nixos-dev
v0|d has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
lovesegfault has quit [Quit: WeeChat 2.7]
drakonis has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<infinisil> I think exactly because of this it's a good idea to have a poll. In the end formats that are known to everybody will be much easier to write docs in than having to learn a new language
<infinisil> Well not because it's easier in general, just that everybody already knows it
<infinisil> I fear if we base our decision too much on "which is the best according to some core members", we'll end up picking not the best one for the average joe
<qyliss> No no no you misunderstand
* infinisil listens
<qyliss> The best format, in that case, is plain text
<qyliss> Because you don't have to learn anything in order to write it.
<qyliss> But, we have needs that plain text can't serve. We need formatting, and links, and things.
<infinisil> Ah yeah, of course only formats which we know can give us all the features we need will be eligible for voting
<infinisil> No point in adding things that can't be used
<qyliss> My concern is this
<qyliss> There is no way anything that could be considered Markdown, either Gruber's or CommonMark, has all the features we need
<qyliss> At least I don't think so
<qyliss> If there is an option called "Markdown" on the ballot, it will win.
<qyliss> Even though it won't be Markdown.
<qyliss> It will be Nix flavoured Markdown, or something else flavoured Markdown
<qyliss> It will win on name recognition even though people won't get what they thought they were voting for.
<qyliss> That's my concern with a poll. This is too much nuance to express in poll options.
<infinisil> Yeah sure, but calling it "Markdown" still means that most of the things it will provide will be compatible with what everybody knows already
<infinisil> We might need to slap some extensions on it
<infinisil> But in the end it's as close to markdown as people would expect
<qyliss> By that reasoning we could call it plain text
<gchristensen> then we're back in the "toolmaker" position
<qyliss> And that.
<gchristensen> I don't think we're equipped to try to parse meaning out of markdown's ill-defined soup
<infinisil> And yes tools are a big factor too, but as long as we have some tool that can convert "some markdown variant" to what we need it shouldn't matter
<infinisil> And learning some minor special extension syntax is still much less work for people to learn than a new markup language
<qyliss> I disagree
<qyliss> And it's a far less useful skill
<gchristensen> hehe
<qyliss> Nixpkgs flavoured Markdown is only useful in Nixpkgs
<qyliss> If you learn AsciiDoc that's transferable to Git
<infinisil> That's true
<qyliss> If you learn RST that's transferable to the kernel
<qyliss> With nothing else to learn.
<infinisil> qyliss: Okay but let's assume we have a version of markdown with extensions that can do everything we need. Using that as a format *would* make it easier for many people, since 90% will be standard markdown which they know already
<infinisil> Yes they can't transfer those 10% elsewhere, and it won't be Commonmark
<infinisil> But it will be easier to get started writing docs
<qyliss> That means we'll get documentation that largely doesn't use any the extensions
evanjs has quit [Quit: ZNC 1.7.4 - https://znc.in]
<infinisil> If the extensions aren't needed then that's a good thing. It's not like many people will use many reST or asciidoc features either
<jared-w> qyliss: how much documentation needs to use extensions? And how much documentation currently makes maximal use of extensions?
<infinisil> Words are the essence
<qyliss> jared-w: have you ever seen a book written in Markdown?
<gchristensen> jared-w: we won't know until we try, and so far nobody has tried making a PoC.
<jared-w> Anecdotally I've seen a lot less linking, examples, etc., in modules because all the documentation is inline
<qyliss> infinisil: then lets use plain text
<qyliss> Clearly, things beyond words are important.
evanjs has joined #nixos-dev
<qyliss> jared-w: every Markdown work I've ever come across that's more than one source file uses extensions.
<infinisil> Words being the essence doesn't mean we don't need anything other than words though :)
<infinisil> The standard features of markdown are enough in very many cases though
<qyliss> Not to produce a manual
<qyliss> I've yet to see it.
<qyliss> The best big Markdown documents are Rust books, and they're full of extensions.
<infinisil> Yeah, but for a user to just write a single section the standard features are enough
<jared-w> qyliss: that's fair. But for inline documentation? Regardless of what document format it's going to have to be ripped out with a nix parser anyway because it's inline with nix code
<qyliss> What about cross-referencing and all the other stuff we apparently need?
<jared-w> that's already an extension. You can't point pandoc at default.nix and have it work.
<qyliss> jared-w: we can't have one plain-text-like format for options and another one for the manual. That would just be confusing.
<qyliss> jared-w: exactly.
<qyliss> oh, sorry, misunderstood
<qyliss> ignore the "exactly"
<infinisil> We can educate people about the extensions
<gchristensen> we could
<gchristensen> that is true
<gchristensen> I think it could work
<jared-w> you're fine. In anecdotal experience, I've noticed that with things like documentation, the 80/20 principle plays *very* strongly here
<qyliss> But we could educate people about a better format.
<jared-w> Same with drive-by contributions. Core people will contribute to whatever VCS they need to, but rando people power come from hosting on GitHub
<gchristensen> like docbook =)
<qyliss> If I'm a drive-by contributer, why would I bother learning Nixpkgs flavoured Markdown?
<gchristensen> probably don't have to
<jared-w> You wouldn't need to if it's just "fixed a few typos and added a link to this other thing"
<qyliss> Fixing typos is the same in any language
<infinisil> And if you write a section in standard markdown, reviewers could point out how to make references
<jared-w> The simple fixes are also the exact kind of tedious, thankless tasks that core contributors simply can't get around to.
<infinisil> It's essentially learning some extensions (which in 80% of cases you don't need anyways) vs learning an entirely new markup language
<qyliss> But core contributetrs can get around to reviewing them and teaching people the extensions?
<gchristensen> copy-paste and very fast turnaround time
<gchristensen> same way I learned Nix
<infinisil> I do have some saved replies in github for the things I have to mention a lot :)
<qyliss> And like, suppose somebody doesn't know how to add a link
<qyliss> The documentation is full of links
<gchristensen> they'll find one and copy it
<qyliss> Exactly
<gchristensen> win!
<qyliss> In the process, they mmight be exposed to more docs and find another thing to fix.
<qyliss> But it's going to take them 10 seconds
<qyliss> on top of that, it took me _years_ before I could remember which way round Markdown's link syntax was
<infinisil> With something like reST or asciidoc we get the benefit of easy to write docs. But if we use markdown we also get the benefit of many people already knowing it, meaning they won't have to learn new things to get started
<qyliss> So I'm not even convinced newbies we're trying to attract will actually be any better off fixing a Markdown link as opposed to anything els.
<infinisil> Regarding that, reST and asciidoc are on the same level as docbook, since many people don't know it
<qyliss> No they're not
<qyliss> Asciidoc and reST are basically like writing text
<infinisil> Yeah I don't mean that
<gchristensen> infinisil++
<{^_^}> infinisil's karma got increased to 181
<infinisil> I mean regarding people having to learn new things, reST, asciidoc and docbook are all relatively new to many people
<qyliss> But, look, it comes down to this.
<qyliss> If it's practical to produce a manual from Markdown, that's readable and has all the functionality we need, then that sounds great.
<qyliss> I don't believe it is possible, at least not with "standard" Markdown.
<qyliss> Where's all the development time to produce a Markdown manual going to come from, btw? Is there an out of the box tool we can use?
<qyliss> But with both AsciiDoc and reST, all this tooling is already there, and satisfies all our requirements.
<qyliss> No non-transferable project-specific extensions required.
<qyliss> If we put this to a vote without having proven that it's possible, we're going to end up stuck
drakonis has quit [Ping timeout: 246 seconds]
<qyliss> Whether we've checked it's workable or not, Markdown would win a poll. Indisputably.
<infinisil> Sphinx uses recommonmark, which has extensions here: https://recommonmark.readthedocs.io/en/latest/auto_structify.html#auto-doc-ref
drakonis has joined #nixos-dev
<qyliss> In that case, it should be listed on the poll as recommonmark
<infinisil> qyliss: I am pointing out in the rfc that if it later turns out the winner can't be used, second place is used instead. But yeah it's probably good to settle what's possible beforehand instead
<qyliss> If we end up having to go with second place _nobody_ is going to be happy
<qyliss> Who decides if it's possible? Who decides when to give up?
<infinisil> recommonmark is a library implementing commonmark + a bit more. And commonmark is just standardized markdown.
<qyliss> These are problems that can be avoided if we have to produce demos first.
<infinisil> I think it's entirely valid to call that markdown
<infinisil> Hm that sounds good
<infinisil> Small demos first that demonstrate all requirements can be met with such a format
<qyliss> Exactly.
<qyliss> And it also demonstrates what it's going to look like
<qyliss> If the extensions are barely needed, we can see that.
<infinisil> Source code you mean?
<qyliss> Yeah
* infinisil nods
<qyliss> If it's extensions everywhere, we'll know that too.
<infinisil> Yeah
<qyliss> But here's another thing I just thought of.
<qyliss> Is it likely that these drive-by contributors are going to be doing the bulk of our doc writing?
<qyliss> That does seem like your thesis
<qyliss> But I'm very sceptical
<qyliss> I think the core contributors will be the people writing most of the docs.
<qyliss> Getting the confidence to write new authorotative documentation takes ages, for me at least.
<infinisil> I think it would be ideal if writing docs to the code you added/changed would become very natural for everybody
<gchristensen> +1
<qyliss> Sure that sounds nice