Migrate binary and default configuration locations away from conduwuit and over to continuwuity

s1lv3r commented

2026-03-12 15:11:39 +00:00

Contributor

At the moment, executables and config files both follow the conduwuit naming scheme. While this does make migrating easier and doesn't have any downsides apart from tech debt, I think it should be considered to migrate everything to the new name.

This was lightly suggested first in the dev channel: https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24OvLOP1y3SASYrHyESa7NEko4u7kePT_vL57nNZgHuHA?via=wolfgirl.pet&via=gingershaped.computer&via=matrix.org

The easiest way to start is likely to rename the example config file as well as documentation. The code already accounts for the old and new filenames, so is unlikely to have breaking changes.

Second change would be to rename the compiled executables. This could pose more of a challenge (e.g. for debian/fedora/etc), as scripts and whatnot might point to the old executable. My suggestion would be to do this in a two-step process:

Rename the executable to continuwuity, let conduwuit be a symlink (something like v0.6.0)
Delete the symlink (v0.7.0)

This would give users time to migrate, and this along with a warning in the admin channel would likely be enough for most users to migrate.

Docker would likely follow a similar path, though implementing this after !1485 could significantly ease the load (as users would no longer have to specify which binary to use).

At the moment, executables and config files both follow the `conduwuit` naming scheme. While this does make migrating easier and doesn't have any _downsides_ apart from tech debt, I think it should be considered to migrate everything to the new name. This was lightly suggested first in the dev channel: https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24OvLOP1y3SASYrHyESa7NEko4u7kePT_vL57nNZgHuHA?via=wolfgirl.pet&via=gingershaped.computer&via=matrix.org The easiest way to start is likely to rename the example config file as well as documentation. The code already accounts for the old and new filenames, so is unlikely to have breaking changes. Second change would be to rename the compiled executables. This could pose more of a challenge (e.g. for debian/fedora/etc), as scripts and whatnot might point to the old executable. My suggestion would be to do this in a two-step process: 1. Rename the executable to continuwuity, let conduwuit be a symlink (something like v0.6.0) 2. Delete the symlink (v0.7.0) This would give users time to migrate, and this along with a warning in the admin channel would likely be enough for most users to migrate. Docker would likely follow a similar path, though implementing this after !1485 could significantly ease the load (as users would no longer have to specify which binary to use).

👍 2

gamesguru commented

2026-03-13 04:48:34 +00:00

Contributor

we need to think about c10y prefixes/abbreviations in places, since this is otherwise a good amount of extra typing...

we need to think about `c10y` prefixes/abbreviations in places, since this is otherwise a good amount of extra typing...

Kimiblock commented

2026-03-13 06:20:08 +00:00

Member

My primary concern is that changing service names may break existing setups of which depends on service overrides.

For binary we can just install a symlink

My primary concern is that changing service names may break existing setups of which depends on service overrides. For binary we can just install a symlink

s1lv3r commented

2026-03-13 09:40:54 +00:00

Author

Contributor

Systemd allows you to have unit aliases, and aliases also load dropins in the same way as the canonical name: https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html

Unit files may specify aliases through the Alias= directive in the [Install] section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is disabled.

In cases of unit aliases (described above), dropins for the aliased name and all aliases are loaded. In the example of default.target aliasing graphical.target, default.target.d/, default.target.wants/, default.target.requires/, graphical.target.d/, graphical.target.wants/, graphical.target.requires/ would all be read.

I.e. we would be able to rename the service to continuwuity.service with an Alias=conduwuit.service and have dropins in conduwuit.service.d still load correctly.

Systemd allows you to have unit aliases, and aliases also load dropins in the same way as the canonical name: https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html > Unit files may specify aliases through the Alias= directive in the [Install] section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is disabled. > In cases of unit aliases (described above), dropins for the aliased name and all aliases are loaded. In the example of default.target aliasing graphical.target, default.target.d/, default.target.wants/, default.target.requires/, graphical.target.d/, graphical.target.wants/, graphical.target.requires/ would all be read. I.e. we would be able to rename the service to `continuwuity.service` with an `Alias=conduwuit.service` and have dropins in `conduwuit.service.d` still load correctly.

gamesguru commented

2026-03-13 10:20:46 +00:00

Contributor

I really think the executable should be abbreviated. c10y or uwu are fine for things that will be often typed

I can't think of another CLI tool whose name is 10 letters long. And continuwuity is 12.

I really think the executable should be abbreviated. c10y or uwu are fine for things that will be often typed I can't think of another CLI tool whose name is 10 letters long. And continuwuity is 12.

s1lv3r commented

2026-03-13 10:56:14 +00:00

Author

Contributor

I can agree with that, though I'd rather name it c10y than uwu in that case

lveneris commented

2026-03-13 11:10:19 +00:00

Contributor

The service is called matrix-continuwuity in NixOS, which is exceedingly long, but in my experience you don't interact with the service enough after you've set it up, much less the binary, for it to matter. That's worth considering. I also don't think most people would expect c10y to be the name; how many commands do you know with numbers in them? I can't think of any. You could have c10y as an alias, but personally I would not expect people unfamiliar with the community to be aware it gets abbreviated as c10y either. You may as well call it cy at that point if brevity is valuable.

Otherwise, this is a solid plan. It'd be nice to have the name consistent everywhere at last.

The service is called `matrix-continuwuity` in NixOS, which is exceedingly long, but in my experience you don't interact with the service enough after you've set it up, much less the binary, for it to matter. That's worth considering. I also don't think most people would expect `c10y` to be the name; how many commands do you know with numbers in them? I can't think of any. You could have `c10y` as an alias, but personally I would not expect people unfamiliar with the community to be aware it gets abbreviated as `c10y` either. You may as well call it `cy` at that point if brevity is valuable. Otherwise, this is a solid plan. It'd be nice to have the name consistent everywhere at last.

s1lv3r commented

2026-03-13 11:12:06 +00:00

Author

Contributor

Hm.. I do actually tend to agree more with you there, yeah. Service executables aren't something that's usually touched, so long names aren't an issue.

lveneris commented

2026-03-13 11:20:04 +00:00

Contributor

On a more relevant note to the issue, it should probably log a deprecation notice if you start the program as conduwuit, alongside the admin channel notice. If you miss one, you should see the other. Redundancy is worthwhile here, since we do not want people to be surprised by the change when the time comes to remove the conduwuit alias.

On a more relevant note to the issue, it should probably log a deprecation notice if you start the program as `conduwuit`, alongside the admin channel notice. If you miss one, you should see the other. Redundancy is worthwhile here, since we do not want people to be surprised by the change when the time comes to remove the `conduwuit` alias.

s1lv3r commented

2026-03-13 11:21:29 +00:00

Author

Contributor

Agreed, that part can likely be implemented before anything else once we move over to the new name. Can draft up a PR once we get things settled properly.

❤️ 1

gamesguru commented

2026-03-13 11:25:28 +00:00

Contributor

The service name I don't type it as often. Sounds like it supports aliases anyway.

No idea if abbreviating the executable is even a great idea... but as a dev, I definitely don't want to test my spelling/typing abilities that often lol

The service name I don't type it as often. Sounds like it supports aliases anyway. No idea if abbreviating the executable is even a great idea... but as a dev, I definitely don't want to test my spelling/typing abilities that often lol

s1lv3r commented

2026-03-13 11:28:18 +00:00

Author

Contributor

Can't you just run cargo run? Optionally we can just make a script for it or something.

I use cargo run --package conduwuit --bin conduwuit -- --config conduwuit.toml when testing and developing at least, ran through my IDE (so i never actually type the command).

Can't you just run `cargo run`? Optionally we can just make a script for it or something. I use `cargo run --package conduwuit --bin conduwuit -- --config conduwuit.toml` when testing and developing at least, ran through my IDE (so i never actually type the command).

lveneris commented

2026-03-13 11:51:58 +00:00

Contributor

There's nothing stopping you from using c10y as an alias while you're developing, I just don't think that should be a thing for the actual release.

Kimiblock commented

2026-03-13 14:39:01 +00:00

Member

Systemd allows you to have unit aliases

Yeah. Though I would still prefer a separate legacy service along with the new service and not having Alias to avoid confusion for existing users. If we are going to merge the service then packages should implement some sort of warning to inform users.

> Systemd allows you to have unit aliases Yeah. Though I would still prefer a separate legacy service along with the new service and not having Alias to avoid confusion for existing users. If we are going to merge the service then packages should implement some sort of warning to inform users.

nex added the

Enhancement

Help wanted

Rows
Columns

Migrate binary and default configuration locations away from conduwuit and over to continuwuity #1536