<infinisil>
I believe that's what that means at least
<samueldr>
it's way too late for that, but it would have been cool to have nixpkgs split in plumbing, and porcelain packages, with the main attrset being the porcelain one
<infinisil>
:O add.interactive.useBuiltin
<samueldr>
so you know that if you change plumbing.git it's not expected to be used by end-users, but by software
<MichaelRaskin>
We kind of have this. It is called stdenv
<samueldr>
MichaelRaskin: it's a limited subset :)
<MichaelRaskin>
Maybe if you want to draw black and white picture, that's where the border should lie. What I want to say is, obviously, stop hoping for black and white picture having exactly the correct nuance.
<infinisil>
The add.interactive.useBuiltin btw seems to not be in current stable git
drakonis has quit [Quit: WeeChat 2.7]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
ixxie has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 265 seconds]
FRidh has quit [Quit: Konversation terminated!]
drakonis has joined #nixos-dev
<infinisil>
So um, do we have a plan for how to move from docbook to something else?
<infinisil>
Is there anybody in the lead for this?
<drakonis>
there's a channel for that
<drakonis>
ah, nevermind, no irc channel but there's a group of people that were looking into it
<gchristensen>
basically we need to do the impossible task, and then the easy task
<gchristensen>
(books isn't a good sales pitch :P) at any rate, working code is pretty compelling
<infinisil>
Books for size
* gchristensen
points to docbook
<infinisil>
Well yes, but you had worries that sphinx is too slow for big docs. The fact that some books are written with it tells us something about how fast it can be
<drakonis>
well, it lets you do books, right? it makes a nix book possible/easy
<drakonis>
and the above
<gchristensen>
my messagesaying a good bet is to experiment
<gchristensen>
sounds like size won't be a problem, let's try it
<infinisil>
"No matter how many git repositories you use, Antora can retrieve and aggregate all the content from them to assemble a documentation site. "
<infinisil>
That looks like something we'd want!
<samueldr>
asciidoc is extremely powerful
<samueldr>
from my experience with documentation ecosystems, moving off from docbook to asciidoc is probably the wisest choice, to not lose features
<samueldr>
oh, I also have a note for documentation about actively looking at a module that does markdown->asciidoc, and evaluate what's gained/lost with it
<gchristensen>
samueldr: that sounsd good
<samueldr>
so the existing bits of markdown in our docs can probably keep being markdown until rewritten
<infinisil>
Yeah I'm starting to get convinced of asciidoc again
<gchristensen>
is there an asciidoctor with a run-time closure of closer to 50MB than 1,000MB?
<samueldr>
I think as of now, the main stumbling block seems to be the gargantuan build closure (comparativeley)
<samueldr>
we'd need the ruby team to assemble to look into the issues
<samueldr>
I wonder if ruby's dependency on gcc can be split in a split output
<infinisil>
Is that really a big problem though?
<samueldr>
yes as docs are built on end-user's systems
<infinisil>
I think it's vastly overshadowed by our other doc issues
<infinisil>
Aren't docs in the cache by default?
<samueldr>
right now docbook has a REALLY smaller closure iirc
<samueldr>
2.6M
<samueldr>
as of right now, asciidoctor brings in deps from X11
<infinisil>
But who builds docs on their own machine without having 1GB free?
<samueldr>
me
<samueldr>
my laptop is always on the verge of 100%
<infinisil>
And why are the docs not cached for you?
<samueldr>
you didn't ask if they were cached, but who builds docs on their own machine without having 1GB free
<samueldr>
if I write docs, I build docs
<infinisil>
Ah yeah
<samueldr>
and I never verified whether docs were cached or not
<samueldr>
948.9M for asciidoctor, vs. 2.6M for docbook5 (as an easily quotable line)
<infinisil>
I'd guess most people won't be bothered by that tbh
<samueldr>
I think niksnut would :)
<samueldr>
an order of magnitude smaller: I think it's likely fine
<samueldr>
(but would still not be ideal)
<infinisil>
I think this is a very much secondary issue and it shouldn't prevent us from choosing any format
<infinisil>
The gains we'll have from better documentation are so much more worth
<niksnut>
no, that's absolutely a blocker
<samueldr>
oh hi
<niksnut>
there is no way we're making nixos dependent on gigabytes of asciidoctor crap
<infinisil>
It's not NixOS, it's just the people who write docs and need to build them
<samueldr>
I'm sure that there are optimizations to do within the ruby ecosystem and asciidoctor builds here
<niksnut>
for example, it would mean that asciidoctor would be pulled in any time the nixos manpages have to be regenerated (which is almost every time)
<gchristensen>
infinisil: like I was saying other times, it is absolutely a blocker :P
<infinisil>
Then we agree to disagree
<samueldr>
I am sure that asciidoctor is the better contender here, but there are fixes to do for it to be considered
<infinisil>
I and many other people couldn't care less about disk usage
<niksnut>
but don't interpret this to mean I'm only opposed because of the closure size
<samueldr>
and I believe it would be a well spent effort in actually putting eyse on that issue
<niksnut>
asciidoc is just a loathsome as every other markdown language
<infinisil>
niksnut: How so?
<niksnut>
because they all have a crappy, poorly specified do-what-I-mean syntax that's fine for writing reddit posts but not for technical documentation
<niksnut>
I can never remember which magic sequence of special characters accomplishes a given effect in the markdown language I happen to be using
<niksnut>
as opposed to say latex where it's easy to remember \chapter{...}
<samueldr>
in markdown I know that <b>hi</b> is boldened :)
<samueldr>
(what, your parser doesn't keep html?? it's a broken parser!)
<gchristensen>
what does it do when converted to man pages? :P
<samueldr>
no one reads those archaic things!
<gchristensen>
help
<niksnut>
anyway, I've been triggered enough :-)
<samueldr>
These shell commands are defined internally. Type `help' to see this list.
__monty__ has quit [Quit: leaving]
<infinisil>
This do-what-i-mean syntax is exactly what makes them easy to write and read though, and this is why they're so loved
<infinisil>
And asciidoc is at least well-defined
<infinisil>
Asciidoc was created to make writing docbook easier to write iirc
<niksnut>
it's not easy to write, I find it very hard to write
justanotheruser has quit [Ping timeout: 248 seconds]
<infinisil>
You find *docbook* easy to write?
<niksnut>
yes, much easier
<infinisil>
Then you're one of *very* few with that opinion
<gchristensen>
this is why I prefer markdown actually. it is trivial to write even if it isn't great for technical documentation. everybody already knows how to write it to some degree at least.
<samueldr>
maybe it's time the technology sector embraces an openly defined format for technical writing like .docx
<niksnut>
and markdown languages aren't easy to read either, because of the adhoc-ness of the syntax
<gchristensen>
yes, samueldr!
<infinisil>
gchristensen: I'm very split between markdown and asciidoc.. markdown because everybody is familiar with it, but asciidoc for a better future
<niksnut>
the technology sector should just give up on bikeshedding syntax and store data as ASTs
<samueldr>
niksnut++
<{^_^}>
niksnut's karma got increased to 14
<niksnut>
then everybody can use whatever editing formalism they want
<samueldr>
(I was extremely fascetious in that .docx remark)
<MichaelRaskin>
samueldr: fortunately we are protected from choosing docx by the fact has zipped references
<niksnut>
basically all of this is a consequence of still being stuck in a punch card formalism
<gchristensen>
niksnut: I tried to get oXygen to gift us like 100 free licenses but they didn't bite
<infinisil>
> paragraphs = [ "This is a paragraph and this is a ${bold "bold"} word" ]
<{^_^}>
paragraphs defined
<MichaelRaskin>
Mmm, is a SmallTalk rewrite of Nix coming?
joko has quit [Ping timeout: 265 seconds]
drakonis has quit [Ping timeout: 240 seconds]
<infinisil>
Maybe we should have a vote on what doc format to use, after discussing them
<MichaelRaskin>
samueldr: I think Docbook is the closest of storing the parse tree of the document! And no, saying «just store an AST» does not really define the format…
<gchristensen>
ideally also after demos
<niksnut>
democracy doesn't work :p
<MichaelRaskin>
Indeed, we have a decision making process!
<MichaelRaskin>
Based on actual deliberation!
<samueldr>
(is democracy choosing after a demo?)
<infinisil>
Alternatively, let everybody vote on how important different aspects are of the format. E.g. Alice says she gives closure size importance 3 while it being familiar has importance 5
<MichaelRaskin>
I wonder if one RFC per proposed format will just jam the process
<infinisil>
And after that we let everybody decide on how good each aspect is for each format
<infinisil>
Then we calculate their total goodness by weighting each aspect
<gchristensen>
niksnut: good grief
<simpson>
If it can evaluate nixpkgs better than Nix, then it can replace Nix~ King of the hill is surely a viable technique that won't lead to gamesmanship~
<MichaelRaskin>
I think having parallel competing RFCs would actually lead to more complicated decision-making than Debian has, no?
<niksnut>
don't think so, you just have a ranked vote at the end
<MichaelRaskin>
We should try. We might even adopt two contraictory RFCs in the end
<infinisil>
What I don't like about choosing votes or ranked votes is that it does'nt say how much better each candidate is than the other
<infinisil>
Which is why I suggested a weight-based approach
<gchristensen>
we haven't even tried any
<gchristensen>
how can we vote on it if we haven't tried them
<samueldr>
your preferred or most hyped horse in the game
<infinisil>
And if we vote based on aspects, there's no way for people to go "I like this one the most because it's the only one I know"
<infinisil>
And it should be a "what's the best", not a "what's the most popular"
<infinisil>
(my major gripe with almost all votings ^)
<gchristensen>
the ugly truth is there aren't bests
<gchristensen>
and if this is trying to get around requirements like run-time closure size via vote, it is probably not a great approach to the problem
<infinisil>
If something is a blocker then it won't be an option to vote for
<gchristensen>
cool
<infinisil>
Well
<infinisil>
If something is impossible then it won't be an option
<infinisil>
A blocker could not be a blocker later on
<gchristensen>
anyway discussing process is fun and all