Node.js devs, imagine npm doesn’t exist. Instead, if you’re nice, you make a list of your dependencies in your README and everyone installs them manually. (Seriously.) Also, you can list names any way you like. So, if a library is called libclutter-1.0-dev, list it as clutter, libclutter, clutter-1.0, … and people will magically know you meant libclutter-1.0-dev (or, more likely, they’ll do an, e.g., apt search clutter to try and find out wtf you meant). Welcome to C/Vala development in 2021.
(Ironically, I just had to manually install two dependencies to compile a work-in-progress(?) Vala dependency manager app.) :)
@aral Which one was this, if I may ask? I’m guessing Vanat. Do share your thoughts on it.
I agree that a simpler dependency management solution would really help Vala. Flatpak kinda solves this for whatever can be Flatpak’d at all. But if something needs to e.g. install a system service or access the list of processes, Flatpak is not applicable.
Having something as simple as npm is a huge undertaking, because it requires either centralizing all packages into a repo or supporting pointing to git URLs and building those — which raises the question of how to build those, since they all use different build systems.
There are a lot of moving parts, and not a lot of coordinated effort going on in this direction.
I don’t have a point here. Just sharing some thoughts.
@dubiousdisc @aral @colinkiama Something like this is what I was talking about with Prince a while ago on Vala's Discord server. While it is true that within the community there are very few resources, we need an NPM-style package manager for Vala
Maybe it doesn't even need to be centralized, maybe just taking the URLs from the GitHub repositories might be enough, like Go does, but we need to do it.
Otherwise, more painful experiences will be shared by devs who try to use Vala
Would be great not to create yet another standard that relies on Microsoft (perhaps git URLs instead of GitHub URLs?) At this point I’d probably settle for a simple standard that just apt installs the dependencies even. (Although, ideally, a more robust solution would keep a separate dev environment to your system environment.)
@aral I would prefer that you could join the server and be able to chat in a more fluid way, although you may not like the idea as Discord is proprietary software
Maybe later with more discussions we can get something solid (like a spec) and see to start working on it. Ideally it would be nice to reuse Vanat's work, so @colinkiama left some issues there
@aral Obviously all this is done in each one's free time, so... It will take a while. For this reason, the more people helping, the better :)
Since all app distribution on elementary OS is Flatpak, I wonder if that’s just the way to go. Use Flatpak for everything, including during dev…
… I’m looking into that but it seems (a) slower (compared to just using ninja/meson during dev) and (b) seems to be harder to debug / integrate with IDEs (like VSCode). On the other hand, your dev env matches deployment + only one tool is simpler conceptually.
@nahuelwexd @dubiousdisc @colinkiama I’m going to try out a Flatpak + Builder workflow for what I’m working on. It Flatpak works fine for dev with Builder, that might be the route to recommend for elementary OS app dev. (Will also look into integration with VSCodium but didn’t look trivial at first glance to get debugging, etc., going. Still on holiday so will have a better look in a couple of days.)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!