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.



(Oh, and every library you install is essentially a global install that is shared with every project you’re trying to build. So basically everything is ~ an npm install --global.)

This is really something an operating system like elementary OS has to tackle for its apps at least if it wants to attract developers (even if, say, the GNOME, etc., folks are happy with the status quo and/or enjoy the right of passage it represents for keeping out the hoi polloi).

· · Web · 3 · 1 · 3

(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.

CC @colinkiama @nahuelwexd

@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

@nahuelwexd @aral @dubiousdisc We need a proof of concept ASAP!

I’m all for improving the developer experience but maybe there’s something we’re missing here. Why do some Vala developers feel hostile about package managers?

@nahuelwexd @dubiousdisc @colinkiama Good to hear there’s thought and discussion around this. Any thoughts on jhbuild?

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

We have been discussing more in depth today together with @dubiousdisc and @colinkiama and have come to some pretty good conclusions IMO

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 :)

@nahuelwexd @dubiousdisc @colinkiama Cool, will do. I’ve learned to hold my nose and use Discord when necessary :P

@dubiousdisc @colinkiama @nahuelwexd Yeah, vanat. Couldn’t get it to run with a simple case.

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.

@aral @dubiousdisc @colinkiama To make developing with Flatpak effective, you need an IDE with built-in support

I use GNOME Builder :)

@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.)

@aral That reminds me of two months ago when i tried to make a local build of Geary to maybe do some visual tweaks. I just couldn't get it to work because of dependency hell / version mismatching, gave up after two days.

@ff0000 I’ve got a better one for you: I got Geary to build and added Fastmail to the list of accounts you could set up easily alongside the surveillance-based Gmail, etc. Pull request was denied. Still legitimises/encourages people to use Gmail to this day. (So maybe you dodged a bullet?)

@aral Sometimes i think people just don't want to even (simply) offer alternatives to people. Not even when they come in the form of PR's.

@ff0000 I’ve been told it has nothing to do with Google being a sponsor of GNOME.

@aral They couldn't see the PR approve button because of the huge wall of Google money

@ff0000 @aral thats really sad. i liked my fastmail account when i had it.

@aral @ff0000 What was the reason for denial of that pull request? Surely it cant be that they only want to support gmail?

@aral @aramloosman ooof a lot of words just to say: neh, just make so that *insert small ethical company*'s integration is just as easy as multi billion company with endless money Google.

@aral @aramloosman @ff0000 @rra That was frustrating to read. Sure, adding easy selection of competitors does nothing to boost competition, okay.

Google adding DDG and Qwant as alternative search options to Chrome, and Apple adding alternative browser options to iOS, must have had nothing to do with antitrust legal action closing in.

Because who would ever think making competition accessible helps reduce anti-competitiveness?

Also perplexing why MS are making it harder to set a new browser. 🤔

@aral @ff0000
Yeah thats uncool :/
To be fair to the dev, I would also say that if one would start to add more providers than 3+more, one would need to redesign the page.
But I completely agree that it is not a solution to simply deny your work on it because it would question some previous work. Otherwise when will anything ever change?

@krag @celia @ff0000 Interesting. I wonder what’s common with these types of pull requests 🤔

@praveen Aha, thanks! I wonder why I’m not seeing it used more. Will have a play :)

Sign in to participate in the conversation
Aral’s Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!