<gchristensen>
well... it is still an eternity away from being part ofborg for real
<samueldr>
from memory, maybe half of the open PRs right now are stalled without work, and unactionable :/ I think everyone shoul check their own PRs and do *something* (self-triage)
<yl[m]>
that's alright, as long as you're actively working on it
<gchristensen>
first I have to extend the github library a lot, which is what I'm doing here
<samueldr>
though, only a tiny fraction of the authors will have read that line :)
<yl[m]>
samueldr: I did that this month, all my open PRs are currently valid
<samueldr>
not to be indiscrete, why the namechange on IRC yl[m]? (no need to answer, just curious)
<gchristensen>
also imo it isn't a problem to have old, open, stale PRs. it doesn't hurt anything. it is just a number.
<samueldr>
I have seen many people assign a sentimental value in a low count of open PRs :/
<gchristensen>
less than 0.2% of the PRs are open
<joepie91>
same for low amount of issues, leading to such bad policies as auto-closing issues after X days of being unresolved
<samueldr>
and have seen discussions where it is thought a project is "sick" when it can't cope (which is not true here)
<yl[m]>
samueldr: I'm considering changing my username to yl everywhere (also on Github it will be ylcodes), but this has stalled for me because at work I shared 100s of Gists with customers and apprently Github does not setup Gist redirects
<yl[m]>
so until I leave my job, I'm stuck
<joepie91>
wat
<joepie91>
they don't?
<yl[m]>
nope
<samueldr>
ouch, they do for repos though :/
<joepie91>
.............
<joepie91>
why is it that no place seems to consider permanence of URLs...
<samueldr>
software as a service was a mistake ;)
<colemickens>
GitHub support is excellent, btw, probably the best support I've ever gotten. They might be at least sympathetic?
<gchristensen>
joepie91: yl[m] is the one not considering it, changing their name!
<joepie91>
<.<
<yl[m]>
I'm aware of the repo redirects, my old username was eMxyzptlk some years back and I still have the redirects
<yl[m]>
I already contacted support
<yl[m]>
they replied with a shrug
<joepie91>
that has also been my experience with their support
<joepie91>
afaik it still does not have PR branch retargeting
<joepie91>
several years after I asked them about it
<joepie91>
:p
<gchristensen>
I've had terrible experience with github support :(
<joepie91>
(and I'm probably not the only one who did)
<samueldr>
one time was "thanks for the information" the other "thanks for the input" :/
<gchristensen>
PRs can retarget now
<yl[m]>
joepie91: I had a good experience in general with their support, well as long as no work is required on their side lol
* samueldr
wonders if the issue still 500s
<joepie91>
gchristensen: to a different *branch*?
<gchristensen>
yea
<gchristensen>
wait, src branch or target?
<gchristensen>
you can retarget a PR, but not change the source
<joepie91>
target
<joepie91>
where is this magical retargeting button?
<colemickens>
:( I got emails back, but I think it's because I keep detecting cases where they silently drop mail... maybe I got the right person's attention.
<joepie91>
gchristensen: oh wow, finally
<gchristensen>
oh man colemickens you're lucky, when they were dropping emails a couple years ago it took six months for them to believe me.
* joepie91
pops open the non-alcoholic pressurized beverage
<infinisil>
yl[m]: Are you sure you want a two letter username? You'll have lots of trouble getting that on all kinds of websites
<yl[m]>
infinisil: yl and ylcodes are going to be my usernames
<yl[m]>
I also own the yl.codes domain now
<yl[m]>
I'm getting rid of kalbas.it
<infinisil>
Hehe, permanence of urls, relevant ^
<yl[m]>
mainly because kalbasit does not fit me well anymore (I'd like to do consulting and it's hard to do consulting with someone who understands russian, means drunk lol)
<yl[m]>
hh yea
<infinisil>
Oh lol
<gchristensen>
lol, the time they sent me private people's repositories by mistake their support channels didn't believe me at all and I had to go around them...
<samueldr>
779 "not wip" PRs though (not wip meaning neither WIP in title nor wip tag)
<colemickens>
what *isn't* a TLD these days?
<colemickens>
gchristensen: oh jeez
<yl[m]>
shoot, gtg, forgot I'm picking up my son. He'll have to wait for me :(
<infinisil>
colemickens: "os" unfortunately isn't one, would be cool for nix.os :P
<gchristensen>
samueldr: you obviously don't speak nixlandianese
* samueldr
wonders who does
<drakonis>
samueldr: that's a lot of PRs
<drakonis>
could definitely take most of those in
<infinisil>
I just closed a couple of mine that I couldn't be bothered with anymore
<infinisil>
We need to recruit more committers!
<drakonis>
agreed
<drakonis>
can i sign up?
<drakonis>
can we also get irc cloaks
<samueldr>
`system_tarball_pc`?
* samueldr
opened the oldest non-wip PR
<gchristensen>
drakonis: sure
<gchristensen>
(cloaks)
<drakonis>
fair
<samueldr>
gchristensen: if it needs to be a real domain name, probably best to (consult owner before) go with nixos.community
<drakonis>
nix cloak but not nixos cloak tho
<infinisil>
drakonis: Have you done any PR's to nixpkgs?
<drakonis>
yes
<drakonis>
4 so far, i do intend to raise that count in the future
<gchristensen>
drakonis: what would your ideal cloak be?
<drakonis>
ideally one that refers to the nix ecossystem instead of the distribution
<infinisil>
drakonis: Reviewed any PRs?
<drakonis>
no PR reviews tho :|
<drakonis>
i gotta get on that at some point
<infinisil>
Yeah, that's something I'd like all committers to have done a couple times
<drakonis>
i haven't done it because my packaging experience isn't there yet
<drakonis>
and we don't have any ratified standards yet
<infinisil>
Hehe, well then I don't think you should be committer yet
<drakonis>
i do agree there
<drakonis>
i do want to help because the number's way too high
<infinisil>
Yeah
<drakonis>
as for the cloak, ideally i'd like it to be the nix/<role>/username format
<colemickens>
looks like I've got 40 merged but I still make some simple mistakes so I don't want merge power. It would be cool if we could have more tooling around ofborg (like K8s's Prow) that could let volunteers do more labeling that could help the people with the merge powers.
<colemickens>
similarly I've been curious if ofborg might ever auto-merge based on tags, etc.
<gchristensen>
agreed
<gchristensen>
it might :)
* joepie91
has been pondering over an out-of-band volunteer triaging system for nixpkgs
<infinisil>
Ahh that reminds me I should finish my dependency graph thing for nixpkgs
<gchristensen>
joepie91: sounsd cool
<infinisil>
Should allow generating a ranking of derivation importance, so ofborg could build the most important ones of the dependents in addition to the package itself
<drakonis>
process all pending package related pull requests and then merge those if its all ok
<drakonis>
seeing as the bulk is either updates or adding new packages
* colemickens
mumbles something about monorepos
<drakonis>
probably would be terrible for having standards
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
aminechikhaoui has joined #nixos-chat
aminechikhaoui has quit [Remote host closed the connection]
aminechikhaoui has joined #nixos-chat
<gchristensen>
api server design changes which breaks api client designs suck
<gchristensen>
essentially requires changing every immutably-borrowed client in to a mutably borrowed client.
<joepie91>
(attack that snatches source code from local dev tools)
drakonis has quit [Quit: WeeChat 2.3]
<jasongrossman>
joepie91: I like your line about Aaron Swartz (on that page).
<joepie91>
:)
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
jasongrossman has joined #nixos-chat
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
jasongrossman has joined #nixos-chat
jasongrossman has quit [Client Quit]
jasongrossman has joined #nixos-chat
PolarIntersect has quit [Ping timeout: 245 seconds]
PolarIntersect has joined #nixos-chat
PolarIntersect has quit [Ping timeout: 240 seconds]
sir_guy_carleton has joined #nixos-chat
sir_guy_carleton has quit [Quit: WeeChat 2.2]
<Arahael>
colemickens: Feels like reactOS has become more and more visible over time.
<Arahael>
Hmm, my user in vim uses fish as the default shell, yet when I run nvim, it seems to default to bash? How do I change that?
<Arahael>
I want the default shell in vim to be fish.
qyliss has quit [Ping timeout: 252 seconds]
qyliss has joined #nixos-chat
ottidmes has joined #nixos-chat
__monty__ has joined #nixos-chat
<andi->
How are people developing haskell? I am a bit confused with the avaiability of syntax checking vim plugins.. Tried ghc-mod which fails some obscure type errors when compiled on 18.09 and with a different one on unstable :/
<Arahael>
I use a combination of brittany and well, just compiling it, to syntax check my haskell.
<Arahael>
Also, I just use the regular vim syntax highlighting as well, but that's *barely* syntax checking at all. It does catch it when I forget to close a string, though.
* Arahael
is a fairly new user to the haskell scene, though.
<srhb>
I do much the same as Arahael. minimal syntax highlighting in vim, a ghcid running in another terminal
<srhb>
andi-: Works pretty well :)
<Arahael>
srhb: Btw, I've gotten over my little rant in #nixos the other day, made a fool of myself it seems! The nixos docs turn out to be exceptional, and stack (which I still like to use) has some additional features that make it particularly nice on nix. :)
<srhb>
Arahael: I've already forgotten that rant. :-P I could rant for ages about stack on nix and how it's horrible!
<Arahael>
srhb: I still wish it was "as easy as Go", but the Go approach for using system libs is to deny that system libs exist! ;)
<srhb>
(I try not to in #nixos though)
<Arahael>
Ha, and thanks for that. :)
<srhb>
After a stack work dir falsely succeeded some builds in production that should have failed, I'm not touching that thing with a ten foot pole :-P
<Arahael>
I must admit, after talking to a few people, I do very much like the idea of - eventually - swithcing to "just cabal".
<Arahael>
But that day isn't today.
<Arahael>
(Only 7 minutes left of today, anyway!)
<srhb>
I mean, we don't even use cabal(-install) in Nix
<srhb>
Ah. :-D
<__monty__>
7 minutes is plenty imho : >
<Arahael>
Right - but I don't have nix on all my platforms. :(
<__monty__>
srhb: Incremental builds though.
<srhb>
__monty__: I'd _love_ to have that, but not at the cost of correctness.
<srhb>
For that I use cabal new-repl
<Arahael>
Yeah, a "production build" should absolutely be correct. I wouldn't mind having incremental builds that - on a blue moon, fails, though, if it's fast.
<__monty__>
What do you mean, cost of correctness?
alienpirate5 has quit [Remote host closed the connection]
<__monty__>
You don't build incrementally for production. You develop with incremental builds, push to CI, which does a complete rebuild, then you deploy if it doesn't fail.
alienpirate5 has joined #nixos-chat
<Arahael>
__monty__: I agree. :)
<__monty__>
I guess you get most of the benefit from new-repl though, with --fobjectcode
<Arahael>
Anyway, G'night! I should get to bed while today is still... Today!
<srhb>
__monty__: That's exactly what I do, yes.
<srhb>
__monty__: nix takes care of building in production, cabal new-repl with shellFor for developer convenience.
<srhb>
I hate that production builds are so slow though.
<__monty__>
Ah, so you were lying when you said you didn't use cabal : >
<srhb>
No... :-P
<srhb>
I use Cabal (via nix) for production builds, and cabal-install for new-repl :-P
<__monty__>
Oh, I read cabal(-install) as cabal the lib nor cabal-install the executable.
<srhb>
The naming conflation is horrid, hence the capitalization of Cabal-the-library :-P
<__monty__>
I don't think it's confusing. If you'd said cabal it'd be straightforward. But cabal(-install) looks like "cabal or cabal-install".
<ottidmes>
I have been using ghci, but I saw you mention cabal new-repl, thinking it would allow me to finally remove all those language pragmas, and it works great, so I am using it now as well. Do you know the benefit of new-repl over repl?
<andi->
I guess I'll try to go the "manual" road then... So far my experience with learning enw things was that the earlier it tells me that I am typing nonesense the better..
<__monty__>
andi-: Ghcid checks on every write. So write often ; )
<__monty__>
Haskell doesn't really have much syntax to get wrong tbh.
<andi->
type checking :P
<__monty__>
Parens, braces, misstyping keywords.
<__monty__>
That's what ghcid excells at.
<andi->
I already ran into a segfault with haskell yesterday.. my motivation did fade a little
<andi->
ok
<andi->
will check that out
<__monty__>
Are you using unsafeAnything?
<andi->
no, I was just trying to use taffybar before I gave up on it and switched to dzen2
<srhb>
ottidmes: It uses the nix-style builds.
<srhb>
ottidmes: (as opposed to repl/ghci)
<srhb>
andi-: recent taffybar is horribly broken and segfaults all over the place, particularly on ghc 8.4.x iirc
<srhb>
The battery indicator seems to be the worst offender.
<infinisil>
srhb: Yeah..
<infinisil>
Tried out taffybar, got segfaults and 100% CPU usage, had to switch back
<srhb>
I actually have something stable now, using an older ghc, and no battery indicator.
<srhb>
But yeah, it's very bad :P
<ottidmes>
srhb: ah cool, I knew Haskell tooling did embrace Nix too some extent, but had not expected this: "However, those names are only temporary until Nix-style local builds become the default."
<{^_^}>
taffybar/taffybar#394 (by IvanMalison, 18 weeks ago, open): Extremely high memory and cpu usage after taffybar has been running for a long time
<srhb>
ottidmes: Do take note that it's "nix-style" and not "nix itself"
<srhb>
ottidmes: But it works very well for incremental rebuilding on top of nix deps :)
<ottidmes>
srhb: yeah "inspired by Nix" ;)
<srhb>
Right right..
<srhb>
One day hopefully we can have our own incremental rebuild system. A la snack, perhaps.
<srhb>
I hear recursive nix would somehow be able to provide this, but it seems to be mostly vaporware so far.
<srhb>
(Presumably by making each .o its own derivation)
<ottidmes>
srhb: I did see something mentioned about Nix yesterday, but I ignored it thinking they mean UNIX, Nix is not the best name in that regards :P
<srhb>
No, it's impossible to search for :-P
<srhb>
I had to train my search bubble HARD.
<__monty__>
Didn't have the same problem. Nix doesn't result in much unix search results.
<srhb>
__monty__: You probably use a superior search engine :-P
<ottidmes>
It helps that nixos and nixpkgs dont really have that problem
<srhb>
Right :)
<ottidmes>
So I just tend to specify nixos even though I might mean nix specifically, seems to work so far
<__monty__>
srhb: Nah, just has all the snazzy spy features.
<srhb>
I'm sort of sad it's called NixOps and not Charon anymore :-P
<srhb>
__monty__: Ah, clever! ;)
<srhb>
Though the fact that Kerberos is already taken made those moons a probably not-good-choice.
<__monty__>
I like the nix - snowflake though.
<srhb>
Same!
<ottidmes>
srhb: I prefer NixOps, the amount of meaningless names we have to deal with is already insane
<srhb>
Is LambdaOS taken?
<srhb>
ottidmes: I see the argument. I just like themes :P
<infinisil>
I like that we can just search for "nix-*" to find nix related commands
<infinisil>
Also third party ones
<andi->
grml grml this bar placement doesn't make much sense to me..
<ottidmes>
I just made my own lemonbar fork and have been using it ever since without problem
<andi->
I am reading up on all those issues regarding window placement... Some say you need the event hooks, the layout hooks etc... neither works.. :/
<ottidmes>
andi-: what window manager are you using?
<andi->
trying to switch to xmonad
<andi->
I just started lemonbar and it just works..
<andi->
I feel tricked.
<gchristensen>
oh?
<ottidmes>
andi-: I tried all bars I could find, and found lemonbar the most to my liking (I prefer programmability vs configurability), and I used xmonad twice for some time, but I loved the idea of it more than the actual window manager, so now I use bspwm
<andi->
I am thinkng the same slowly..
<andi->
also the brittle bits in haskell that I see everywhere again.. people changing APIs, obscure bugs.. not sure that is really what I wanted tog et myself into.
<ottidmes>
andi-: that is what made me move away from it, that kinda ruins the whole fuzzy feeling of being able to configure your window manager by using one my favourite programming languages, having to deal with obscure details/bugs
<andi->
switched back to i3 for now.. Time to work on my todos for today before I derail furhter
<__monty__>
andi-: You actually *do* the stuff you put on todo lists? I thought they were just for the accumulation of tasks that could've been done.
<andi->
__monty__: I try very hard
<andi->
I wiped it a few weeks ago and starting over since then
<srhb>
Hmm. Anyone had Rimworld sound break recently?
<colemickens>
gchristensen: not to be too opinionated but have you considered bot commands instead of tigher integration with github specific apis?
<gchristensen>
colemickens: these commands aren't also bot commands :)
<__monty__>
srhb: Good to see not everyone is frantically working throught their todos ; )
<srhb>
__monty__: I had yet another insane week and just want to turn off my brain completely. And eat many burgers.
<srhb>
:P
<__monty__>
Sounds like a plan : )
<srhb>
As these things go, of course I get to debug pulseaudio instead. Q_Q
<srhb>
#linuxtroubles
<__monty__>
Better than debugging apple stuff. Follow these 5 simple steps and then it'll work. It's not working? No no, it's working. But it's not working! No no, it's working. fml
<srhb>
lol
<srhb>
I sympathize :P
pie_ has joined #nixos-chat
<gchristensen>
colemickens: the real goal of this is to get build output somewhere other than comments
<colemickens>
Hm, what's the tradeoff between: having the bot do a summary comment and clean old ones, having the PR build status lines with links to logs, having the Check implementation?
<colemickens>
The guess the former litters the thread one way or the other, and I guess Check is just the newer fancier version of the second option.
<gchristensen>
and we can have build failures be warnings instead of failures
<pie_>
srhb, sounds at least cursorily appealing and from what little i know about the nix ecosystem, will probably be great? :P
* pie_
pours himself a bowl of nixflakes and milk
<drakonis>
i'll take that
<srhb>
pie_: overlays more or less tightly integrated with the regular tooling is something I think is a great idea. There are things about the proposal I don't like that's unrelated.
<srhb>
pie_: But nix build flake:nixwine:starcraft would be excellent :)
<pie_>
srhb, have i ranted at you about how there should be two levels of versioning in nix but it only has one and i dont know what to do about it? :P (well probably not >do< much since that would be a lot of work xP)
<pie_>
srhb, hehe
<srhb>
I don't think so. However, I'm probably not very rant-receptive today :-P
<pie_>
actually i think i just thought of a good way to summarize. nixpkgs and channels should be orthogonal
<srhb>
Not sure what that means?
<srhb>
Regardless, I'm no fan of channels.
<pie_>
srhb, a repository of packaging information (possibly containing various versions) and something for provinding a set of packages that a current system should use
<drakonis>
srhb: agreed, it'd make for a flatpak killer
<srhb>
pie_: So I guess what you want is to separate out all-packages.nix
<pie_>
as it is, something in nixpkgs can only refer to whatever is in the repo at the commit it exists in
<pie_>
let us call the commit at which a package being executed in, the eigencommit :P
<pie_>
you cannot refer to other versions of packages in other commits, only your eigencommit, and if there is "subrepo" (say haskell packages) that only has some latest variation, things break
<pie_>
when you update your nixpkgs
* pie_
is apparently of the "/somehow/ subsume all other package managers" party :P
<srhb>
lol
<pie_>
so you have the nixpkgs version, and the versions of software things want
<srhb>
"Imagine a field of packages, in some space S, ..."
<pie_>
xD
<pie_>
drakonis, now imagine nix bundling nix on an app level? :P (idk maybe that makes no sense)
<drakonis>
that'd... be mostly okay?
<drakonis>
nix is surprisingly small
<pie_>
is it?
<pie_>
maybe it just has a lot of pieces
<pie_>
i mean i never felt its particularly small but i never looked into that
<pie_>
maybe its just ram usage thats crazy
<drakonis>
the full package is 12mb
<drakonis>
with some tooling it could take on flatpak
<drakonis>
but its work that someone has to undertake
<drakonis>
there was a pull request i found, that was based on a nixos tree from many months ago
ninjin has quit [Quit: WeeChat 2.2]
<__monty__>
infinisil: I know it's not the same but Wire does have desktop apps.
ninjin has joined #nixos-chat
ninjin has quit [Quit: WeeChat 2.2]
ninjin has joined #nixos-chat
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-chat
pie_ has quit [Ping timeout: 252 seconds]
ma27 has quit [Ping timeout: 252 seconds]
ma27 has joined #nixos-chat
drakonis is now known as drakonis_
drakonis has joined #nixos-chat
pie_ has joined #nixos-chat
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-chat
pie_ has quit [Remote host closed the connection]
__monty__ has quit [Read error: Connection reset by peer]
__monty_1 has joined #nixos-chat
__monty_1 has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis_ has quit [Ping timeout: 260 seconds]
<joepie91>
ohhh, flakes look relevant to me
* joepie91
is generally in favour of anything that can ergonomically support granularly-scoped package sets
pie_ has joined #nixos-chat
ninjin has quit [Remote host closed the connection]
ninjin has joined #nixos-chat
<elvishjerricco>
I wonder if there's any hope of ever being able to virtualize Linux on iOS. That new iPad Pro hardware is insane, but iOS is just too limiting. Virtualizing another OS doesn't seem fundamentally against the security model of iOS, so it'd be awesome to just run Linux directly on that hardware.
<elvishjerricco>
gchristensen: Yea I saw that. That's what prompted this line of thought for me :P They're doing manual emulation of x86, not native execution of aarch64
<gchristensen>
wow
<elvishjerricco>
But if iOS just supported KVM or whatever, we could just run Linux itself without compromising the iOS security model. Would be sweet.
<gchristensen>
so, uh, anyone want to review some wacky Rust code I wrote for me? :)
<colemickens>
I'm not qualified to, but I'm fascinated with your use of Rust to do CI stuff and plan on stealing inspiration at the very least :)
<joepie91>
that's a generally cultural thing over in Rust-land, it seems; taking the time to evaluate different options and designs before settling on something, even if that means things are in flux for quite some time
<joepie91>
which has upsides and downsides :P
<gchristensen>
yeah, it sucks for me
<gchristensen>
I have limited time and chasing updates feels like a waste
<joepie91>
gchristensen: honestly, it's really just a more centralized version of the "new library for the same thing every month" problem
<joepie91>
one way or another you're going to have to pick between 'churn for a while' or 'get stuck with a shitty API forever'
<joepie91>
not really a good solution to it :/
<joepie91>
there's not *
<joepie91>
I suspect things will settle down in the next ~2 years or so
<gchristensen>
I dunno, the time crate's api seems pretty good and stable
<gchristensen>
and yet, 0.1.x
<joepie91>
gchristensen: there's often more subtle issues in an API design that you only find out about much later, once people have started using a thing in production code, and sometimes that requires a complete breaking redesign of the API to rectify
<gchristensen>
sure
<gchristensen>
we can make a 2.0.0!
<joepie91>
then you'd just have the same problem though :P
<joepie91>
1.x would stop getting updates
<gchristensen>
no, because with semver 0.x.x has no rules about api compatability
<joepie91>
the version numbers are different but the problem is ultimately the same, you're stuck on an old-design branch that is not updated anymore
<joepie91>
right, I mean conceptually, not semver-wise
<gchristensen>
I'm talking semver
<joepie91>
any breaking API design is going to result in a new conceptual branch that you're not on but that will exclusively get future updates
<gchristensen>
any update at all can be totally api-breaking
* samueldr
is in a love-hate relationship with bisecting the kernel
<joepie91>
gchristensen: sure, but given the rather strict specifications in Rust, it's very easy for any change at all to break compat
<joepie91>
so "it will break every version" is not an unreasonable assumption
<gchristensen>
:|
<joepie91>
(in the initial design-and-figuring-things-out phase)
<gchristensen>
so the nihilist approach, then
<colemickens>
what does "rather strict specifications in Rust" mean?
<colemickens>
Cargo version ranges? the language somehow itself makes this harder? I didn't understand that.
<joepie91>
it's more that the more strict the rules in the language are, the bigger the impact of an API change is likely to be, and versioning practices tend to reflect that
<joepie91>
colemickens: the language itself
<gchristensen>
I think just borrows / mutable borrows
<colemickens>
I just see it as a result of the fact that Rust has been slow to stabilize given their desire for backward compat AND progress via epochs, and then that mentality trickling to lib authors
<colemickens>
ah yeah joepie91 I see, and agree
<gchristensen>
anyway, when all this is said and done: the one regret I have about picking Rust is how so much of the ecosystem changes.
<joepie91>
gchristensen: if it's anything like JS - which had a similar problem for a long time - it'll settle in a few years :)
<gchristensen>
at least it is past the days where basically every crate required nightly
<joepie91>
but right now it's a reason why I don't recommend people to build big prod stuff in Rust yet
* colemickens
can't tell if the JS comment was a joke
<joepie91>
no, not at all
<joepie91>
contrary to popular memes, the JS ecosystem has actually stabilized pretty well
<joepie91>
sure, there's still HN-frontpage-framework-of-the-week nonsense, but all the things that were around two years ago are still actively maintained and updated today
<samueldr>
there's this one major js project which I hope is stabilized this time ...
<joepie91>
or well, most all anyway, some churn is always to be expected
<samueldr>
... but webpack is a thorn in my side for a couple of long-lived projects :/
<gchristensen>
(sometimes I miss PHP)
<joepie91>
for the less complex problems, many modules have been stable for 3-4 years now
<joepie91>
samueldr: I've recently switched back to Browserify and it's been a great change
<joepie91>
shit just works, none of the webpack bullshit
<joepie91>
and browserify has also stabilized :P
<samueldr>
I'll have to look at it in time
<samueldr>
don't remember if that one I looked at it, but my needs weren't fulfilled by most others I looked at until I used webpack (1)
<joepie91>
yeah, it was that way back when webpack 1 came out
<joepie91>
but browserify has actually moved forward
<samueldr>
webpack still fulfills my needs... but I need to re-learn everything each major releases :/ (now at 4)
<joepie91>
things like HRM work in Browserify now, too (for some value of 'work', because HMR is super unreliable in general)
<samueldr>
heh
<joepie91>
there's a bundle splitting analog
<joepie91>
etc.
<joepie91>
you can even do GLSL bundling
<joepie91>
:P
<samueldr>
I'll try to remember to look at it next time I need to update webpack
<joepie91>
that is my current 'development server' setup for a project
<joepie91>
integrated into an existing Express app
<joepie91>
(the NOTE is there because I need to file a docs bug about that)
<joepie91>
but yeah, this will either run in dev server mode with hot reload and livereload injection for CSS (if NODE_ENV=development), or in prod mode (no dev server, just the express app)
<joepie91>
and it just... works
<samueldr>
though, even if I need to re-learn and gripe every webpack (major) updates, every update makes my specific particular things easier to do, at least there's progress
<joepie91>
samueldr: (worth noting that this is _not_ generated code - I put this together purely based on documentation, which is damn nigh impossible for the Webpack equivalent)
<samueldr>
it's been about 6 months since last time I had to touch webpack-related things, so everything is in cold memory storage, no idea what the equivalent in webpack would be :)
<joepie91>
samueldr: what does your setup do, feature-wise?
<samueldr>
mostly, splits vendor codes in a bundle, app code in topic bundles, those are not issues
<joepie91>
right, you'd add... factor-bundle? for that in a browserify setup
<samueldr>
what I do want, though, and is not easy with every tools, is less-based CSS, which compiles into one file, with a couple nicities, like embedding (some) svg images, controlling the color of the SVG image at embed-time
<samueldr>
I'm going against the flow of the hivemind most of the time in CSS-land
<Arahael>
not neccessarily a bad thing.
<samueldr>
harder to get the results sometimes :)
<Arahael>
but... i like being able to hire a css geek, and in like 30 minutes have a fantastic looking site.
<samueldr>
there's an SVG loader which will take the ?fill and do its magic, then the svgo loader on .svg optimizes it (with loss)
<joepie91>
that + less = done
<joepie91>
no webpack needed
<samueldr>
joepie91: thanks :) though yeah, I'm not looking *yet* for other solutions
<joepie91>
samueldr: just make a note of it, for the next breaking webpack change, where you realize that removing the CSS setup from webpack is probably faster than trying to port it to the new version :D
<samueldr>
I think the way they changed it for 4, it shouldn't be an issue for a while
<joepie91>
that's what people said about 2, and look what happened <.M<
<joepie91>
<.< *
<samueldr>
(3 or 4, memories still in cold storage)
<joepie91>
seriously though, I've lost all faith in webpack ever having either a reasonable design or reasonable docs
<joepie91>
been burned by it too often
<samueldr>
haha
<samueldr>
I do understand
<joepie91>
the maintainers don't seem to understand how to design a good build tool
<samueldr>
the fact that I don't touch it often, like once a year, makes it less of an issue to me I guess?
<joepie91>
mmmm, I've just found that to increase the cost of changing absolutely *anything* because whatever new feature I need *demands* that you use the newer webpack
<joepie91>
because there are no working loaders for older versions
<joepie91>
that have that feature
<samueldr>
yeah
<joepie91>
so like, you're good right up until you need to touch anything and then it all comes crashing down
<joepie91>
very fragile :(
<samueldr>
that's my experience too, which is why I'm frustrated with it :/
<joepie91>
it's what drove me back to browserify :P
<samueldr>
but when it works, it works, so until it stops working, it'll be what's used at $client :)
<joepie91>
lol
<samueldr>
at least it's decoupled from the libraries used by the app
<joepie91>
I still find glslify to be one of the most impressive things in this area