- A package manager. This will help the project grow and mature.
- I didn't find how to call JS functions and vice versa. Should I wrap js code into web components and do interop through props and events, or is there another approach?
I wouldn't follow this approach because if you run `. .env;` you .env gets evaluated as a bash script, not as a configuration file. This means that you can get runtime errors in the .env file, and nobody wants that.
Sourced environment scripts in the Unix environment are standard operating procedure. E.g. for toolchains.
The .env being evaluated as a shell script means that it's in a widely used language, with a widely known syntax. You can look at it and know what it's going to do.
The .env being a data format to some uncommon utility; that's anyone's guess.
For instance, suppose we want a newline character in an environment variable. Does the given "env file" format support that? How?
There is one de-facto standard format: the /proc/<pid>/environ kernel output format on Linux. The variables are null-terminated strings, so it is effectively a binary format. It represents any variable value without requiring quoting mechanisms.
Sometimes waiting for the address is not enough. For example, you might want to wait for a specific API enpoint to return 200 OK, or you might want to wait for database migrations to get applied. Is `is_ready` aiming to cover those cases in the future?
Interesting idea for a feature request. I would love to read a GitHub issue with your specific case so I can start investigating and think about how to solve a problem like this.
I considered starting to write myself a Rust "wait for it" app myself this past week with more features than the standard one. Not sure how I didn't come across yours during my initial search.
There could be some useful functionality that could be found in startup and health probe topics [1] in Kubernetes for example. But at least in that world, it may be easier, and more transparent, to plug in a startup bash script to run before the main app. For example the Postgres Docker image [2] will run any scripts that may be mounted in a docker-entrypoint-initdb.d directory before starting the server. So putting a bash script in a ConfigMap that gets used as a disk volume, could be easier that downloading/auditing a binary "wait for it" container image.
`process-compose` is a "scheduler and orchestrator". `is_ready` only checks for services to be ready so it seems great when you want to start the services by other means and wait for them to be avialabe (for example, services started in another node of a cluster).
A bit off topic, but this is why I started using KDE over gnome. I liked to use middle mouse button for drag-move/resize but in gnome it required editing the source code and recompiling.
The fact that in KDE, not only can I configure literally every pixel at times, I often must configure all kinds of things.
I very much prefer highly opinionated software for three reasons.
That softwares' defaults matter everything, so they are well researched and thought out. While with configurable software, defaults are often accidentally, historically, or whimsically defined.
Settings combine. One setting of two options gives two variations. Four such settings 16. Now imagine the combinations of a KDE app with a hundred settings, many of which can take several values. It's impossible to support, test, understand and debug all these combinations. Yet they often affect eachother. Updates in KDE were, for this reason alone, a break-fest. But even flipping some check boxes often brought my KDE in an invalid state so that (seemingly unrelated) parts would just stop working.
But most importantly, I realized my time is best spend on efficiently using software, rather than spending time on making it work efficiently for my personal workflows. I.e. better to adapt my workflow to some well thought out default, than to waste time thinking out that workflow myself. I still have vim and my shell configured, but that's where I spend almost all my time. For the rest: just vanilla Ubuntu with some nice wallpapers. It has "just worked" for over a decade and many updates now. Which is a much bigger timesaver than configuring the amount of pixels of grab-space of my window borders will ever be.
A lot of care has been put in the defaults in KDE (recently?). They have even set double click to open by default in Plasma 6, though most of the team actually prefers single click, recognizing that it's what users coming from other environment are used to.
Today, the default configuration in KDE software is well thought and usable as is. You don't need to change anything. But you can if you want.
I've used KDE for years now, and when I set up a new environment, I don't change much actually. It's ready to use out of the box.
You don't need to choose between "configurable but painful to set up" and "opinionated and non configurable". "Configurable with 'opinionated' defaults" is also an option and to me that's what KDE provides.
I ditched it entirely during the KDE 3 fiasco.
Been on Gnome/Ubuntu ever since.
But I have tried it now and again, and found that while it's much better than KDE 3, it's still a poor experience out of the box, for me. Or at least, Kubuntu is. It's OK, but not "Good".
For me, the tell-tale is that when my immediate thought is "hmm, maybe I can configure this", something is not right (for me). With Gnome, sometimes I have this (e.g. Gnome Console which has IMO insane default window sizes).
Personally, I think this should never be a setting. Just Good defaults, maybe through heuristics (last size after resize? fullscreen? x% of screen size?).
With KDE I have this all the time. Literally every app that I opened, be it the PDF reader, or the document Scanner, do I immediately go "Something feels off, maybe I must change some settings?" and the answer almost always is in those settings.
I'm not demanding. On contrary, I prefer others with more expertise (of console sizes, PDF displaying, Scanner UI) to make decisions for me, so that I can focus on what I do best instead.
I understand that there's a need for highly configurable software. That my preference of getting force-fed strong opinions is not for everyone. I really do. But I'm using KDE here as an example of what "configuritis" can lead to.
Which KDE 3 fiasco? Are you thinking of the first releases of KDE 4 which were buggy?
It appears to me it's not the fact that KDE is configurable that you dislike, but the design and default configuration choices or the bugs. Or its differences with what you are used to.
I 100% agree with you that the desktop environment should come with good defaults and you shouldn't need to mess with the settings. Life is too short for pointless configuration.
But you are not actually pointing to anything specific so it would be hard to discuss in details or (dis)agree. Not that it's actually an issue, of course. But we can't take any particular insight from your comments other than "this person doesn't like KDE for some reason". If you pointed us at some actual dumb defaults that you shouldn't need to configure but need to, we could actually get your point. The only example you gave is for Gnome, actually. I don't remember struggling with the terminal size on Gnome but then again, I pretty much always maximize all my windows or put them on a side of the screen with a keyboard shortcut, and use tabs so I don't actually create a new terminal window too often.
The problem with GNOME "researched and thought-out opinions" is that they often require all apps to follow it to work well. They ignore use cases involving non-GNOME apps (case in point - systray), but using only GNOME apps is extremely limited.
I used GNOME as my main IDE since v2.4 (2003), but slowly grew frustrated with the changes until the v40 was a bit too much and finally gave KDE a chance (after several previous tries which did not convince me). KDE was finally mature and stable, it took maybe 30 minutes to configure it to my liking - I don't think I had to change the config since then.
> The fact that in KDE, not only can I configure literally every pixel at times, I often must configure all kinds of things.
Neither of those things are true when it comes to KDE. While it is more configurable than GNOME, it's not a particularly high bar to pass, and it comes with perfectly usable and reasonable defaults out-of-the-box.
> Time Zones often have a "friendly name" in the format Continent/City|Island
Continent/City are not friendly names, they are political boundaries that gice more precision. For example, CET covers many countries that might decide to stop applying DST at different points in time. If you store CET in your database you won't know if you need to apply CEST or not. This is why you always need the Continent/City form if you want to be future proof (and past proof)
If you want to be future proof, you need to store locations, not timezone identifiers. The timezone database does not claim that its currently defined timezones are controlled by a single entity (i.e. one timezone can span multiple governments with timekeeping authority), nor could it possibly guarantee that in the face of changing borders and laws.
Time in the U.K. is europe/london. It’s entirely possible in the future that outlying Scottish islands may decide to keep DST while the rest of the country goes to year round daylight saving.
- A package manager. This will help the project grow and mature.
- I didn't find how to call JS functions and vice versa. Should I wrap js code into web components and do interop through props and events, or is there another approach?