Bit surprised, and disappointed to not see dynamic field support for the uv build backend in this update. Need it for dynamically getting the version from Git. Is there anything blocking it, or is it just not important enough?
Unfortunately dynamic metadata is not efficient for package resolution, so we don't want to encourage it. Instead, we want to design a better workflow for using source control for versioning, but haven't had the time to do so.
Interesting, a better way of doing versioning would be nice. The tool I use requires a git repo setup with at least 1 commit, annoying for brand new projects. I'll be eagerly waiting to see it eventually.
At what point is that the case? When a package is built, it's version is determined at that moment from whatever dynamic source, and is then written into the metadata in a static way (or surely could be if for some weird reason it isn't).
I've been dealing with this exact problem this week. For being such an established protocol with such strong servers, the open source clients available are shockingly undercooked.
I've been playing around with using XMPP as the communication layer for some agents, but the popular client apps (converse.js on web, conversations.im on android) have such little polish.
I've had to fork them to make them pleasant to use at all, this feels like it should be a solved problem.
Mine wasn't. I lost my main account as I couldn't verify I owned it given it was bought on a whim years ago through a giftcard, and they didn't have many recovery methods for those users. Then they permanently deleted the account after the transfer window was over. Luckily I had a second account I could transfer, but even if I could transfer the other account, you cannot have multiple Minecraft accounts tied to a single Microsoft account and having multiple Microsoft accounts is against TOS.
You couldn't verify you owned it because you didn't have access to the email presumably? What account system doesn't work like that?
Also - having multiple Microsoft accounts is absolutely permitted, I have multiple due to their Xbox profile messiness (it is possibly to detach Xbox profiles and they can't be reattached if you ever navigate to the Xbox website while it's detached...) and senior support endorsed it as the recommended solution.
Makes me wonder if all non memory safe code will be on the chopping block in the next 5 years. Will they find it morally justifiable to "protect" people from evil unsafe languages?
Let this be a reminder to never trust any service be it one ran by a billion dollar company, to one ran by volunteers. You will be eventually screwed over. Make backup plans, and self-host whatever you can so nothing can be taken from you. For Git forges, I personally recommend Gitea[1], or Forgejo[2] (a Gitea fork by Codeberg)
Yeah. Buying my own domain and migrating my email to it is one of the best things I've ever done. Setting up wireguard into my LAN permanently changed the way I used computers. Looks like it's time to get myself a VPS and just start hosting even more stuff.
Sovereign personal infrastructure is amazing. Highly recommended. Dealing with the government's rules and their politics is obnoxious enough. I'm starting to really lose patience with all of these communities.
Self-hosting based on an external project is still a dependency on Someone Else to keep it up to date, unless you have both the time and skill to take over maintenance of that project.
It’s probably not too important to choose a service that you think you can trust fully, because that trust might be broken at some point. But having an identifier that can be swapped to different backends, so people can find you again when the host inevitability changes, is a stronger strategy.
I think the importance of owning domain names will increase, and using those as the canonical identifier of a project will give it more permanence. The procedures for seizure and censorship with domain names are better established and understood.
I’m referring to the self hosted part. The outside world can send pull requests via the public GitLab mirror, or they can actually also access my self hosted GitLab instance via its public address - although I doubt anyone would bother.
(Pull requests also can, and should, be sent via ways such as submissions to mailing lists.)
The complexity involved. Most people just want to get on with their work and not get lost into details of self hosting (plus maintaining) yet another service. probably they've self hosted sth else and they're spread thin on resources.
reply