opend in package managers (homebrew and chocolatey)

[SingingBush]

It would be handy to have opend available in install via Homebrew on Mac and Chocolatey on Windows. Ideally this should be maintained by opendlang to prevent the situation in which they stop getting updated (dmd on Chocolatey is still 2.100 from 2022). A potential issue with this would be that if a user has both dmd & opend installed via these methods there will be a conflict on the users path as both packages have a dmd binary that will be added to the users path.

On Fedora this issue is handled by alternatives but I'm not sure if either Homebrew or Chocolatey have such a feature.

It would also be helpful if there was an official setup-opend GitHub action (similar to setup-dlang) so that users of OpenD can conveniently setup github actions.

I understand that anyone could set these things up but I think it would be best if they were owned by the opendlang organisation. I'm willing to help if required. Potentially could do the initial work to get this working and transfer over to opendlang once done if that's acceptable.

edit: btw, I think opendlang would be a better package name than opend

[adamdruppe]

A potential issue with this would be that if a user has both dmd & opend installed via these methods there will be a conflict on the users path as both packages have a dmd binary that will be added to the users path.

This is why the opend wrapper program doesn't actually need dmd in path; it checks its separate directory to find it explicitly. So this should be manageable by only putting the opend program in the path (which is how i do it on my own computer).

I understand that anyone could set these things up but I think it would be best if they were owned by the opendlang organisation.

Yeah, I'm not opposed to any of this, I just don't know anything about it (I guess im kinda oldschool in that im all about those tarballs). A few things to keep in mind:

• the opend package itself must not be separated. That'll break everything. So keep it together, put the wrapper alias or whatever in the path that points back to it. Probably c:\program files\opendlang on windows, /opt/opendlang on linux (or i just put it under my home directory on all of them, that could prolly be an option too since it doesn't actually need admin account to use) and mac does the app directory too so do that there
• the opend package can be updated kinda at random, i do it by git pushing. it has a stable link but the contents change so if you try to hash based on that or something. but the package managers could take certain snapshots
• some of the opend commands, like install xpack- will try to write to its directory

So I don't think any of that is a big deal just something to keep in mind.

[SingingBush]

Thanks for the info. I'd be happy to do the initial work but I think getting the ci to produce versioned release builds should be a prerequisite. A hash of the build artifacts are usually used, I'll see if it can be done without them.

[adamdruppe]

Could maybe take one of the snapshots and just reupload it as a release, but I have avoided keeping old versions around because they're not supported; if someone finds a bug in an old version, the first thing they should do is try the new version to see if it is already fixed. If it isn't, getting the fix will mean.... getting a new version, in which case the old one is obsoleted. All changes try to avoid major breakage, but if something is broken, the old branch is abandoned, so there's no practical benefit to trying to stay on an old version; it just becomes unsupported, so there's no difference between putting on a number on it and you just keeping your old version of the artifact.

When it does print a "version number", it is just the build date.

$ opend dmd
DMD64 OpenD Compiler v2.107.0-beta.1
 Thu Jul 31 14:04:52 2025

(the 2.107 is leftover from the fork point from upstream)