<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>
aanderse: oh yes please
<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
<adisbladis>
aanderse: <3
<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
<adisbladis>
gchristensen: Well, there are a few "standard" abstractions
<adisbladis>
proxy passing, cgi, fastcgi, wsgi
<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
<adisbladis>
But could be extended with "for mastodon+nginx apply this specifically"
<drakonis>
now for proposals 6 and 7
<aanderse>
but working on shrinking the gap between the awesomeness of the nginx and httpd services
<adisbladis>
aanderse++
<{^_^}>
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.
<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?
<adisbladis>
Most applications are simpler than that
<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>
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
<tazjin>
8440abe7e6f8f85eca9fd8ad9f8471971202c905
<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
<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 : >
<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
<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>
Maybe more can be added too, I think I saw something about this
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