# Proposal: rename some dirs
**URL:** https://forum.syncthing.net/t/proposal-rename-some-dirs/22766
**Category:** Development
**Created:** [September 9, 2024, 9:05am UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766 "2024-09-09T09:05:36Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [September 9, 2024, 9:05am UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766/1 "2024-09-09T09:05:36Z")
Syncthing naming proposal
I propose to slightly rearrange our source directories/packages.
## Move cmds
Primarily, I’d like to have only useful, user-facing commands directly in `cmd/`. We move commands that are for backend infrastructure to `cmd/infra/` and development/experimental/random stuff to `cmd/dev/`. Specifically, these stay where they are:
- stdiscosrv stays where it is
- strelaysrv stays where it is
- syncthing stays where it is
These are moved to `cmd/infra`:
- stcrashreceiver → infra/stcrashreceiver
- strelaypoolsrv → infra/strelaypoolsrv
- stupgrades → infra/stupgrades
- ursrv → infra/ursrv
These are moved to `cmd/dev` (and a case could be made for just `rm -r` on several of these):
- stcompdirs → dev/stcompdirs
- stdisco → dev/stdisco
- stevents → dev/stevents
- stfileinfo → dev/stfileinfo
- stfinddevice → dev/stfinddevice
- stfindignored → dev/stfindignored
- stgenfiles → dev/stgenfiles
- stsigtool → dev/stsigtool
- stvanity → dev/stvanity
- stwatchfile → dev/stwatchfile
The end result is hopefully that it’s a bit clearer which things are meant to be built and distributed for the general user base and which are not.
## Rename lib
Our `lib/` should really be `internal/`. It even was, for a while, but then we added the discovery server and such as external repos and renamed it to `lib/` so those could build. Then we moved those back in-house, but didn’t change back.
Which external things currently depend on this and would break? The iOS/mobile linking thing? The C++ linking thing in syncthingtray?
---
### Author:  [@AudriusButkevicius](https://forum.syncthing.net/u/AudriusButkevicius)
#### Post date: [September 9, 2024, 11:48am UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766/2 "2024-09-09T11:48:23Z")
I think internal would break people depending on syncthing as a library, so is it really worth it?
---
### Author:  [@acolomb](https://forum.syncthing.net/u/acolomb)
#### Post date: [September 9, 2024, 6:46pm UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766/3 "2024-09-09T18:46:23Z")
I don’t see a large enough benefit from the `lib/` → `internal/` rename. Sure we don’t treat it as a public interface library, as that isn’t the “product”. But when keeping up with the development pace, there is nothing wrong with using it as a library either. I think the current naming is fine and it gave me a pretty sharp idea about how those parts of the code are used. Changing it would introduce quite some source code churn.
Regarding the `cmd/` restructuring, I’d welcome that part. It’s a bit crowded in there and we don’t have good documentation (anymore, it’s heavily outdated) about what is what.
Whatever we decide, it will be worthless without an associated docs update, getting that up to par again: [Syncthing Development — Syncthing documentation](https://docs.syncthing.net/dev/intro.html#source-code-layout)
---
### Author:  [@imsodin](https://forum.syncthing.net/u/imsodin)
#### Post date: [September 9, 2024, 9:15pm UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766/4 "2024-09-09T21:15:03Z")
Yep, the ios app uses lib/syncthing - c++/syncthingtray afaik does not, that attempt was abandoned. In principle I like moving everything to internal, except lib/syncthing. Afaik that clearly defines the expectations, nobody should depend on our code as we don’t treat it like library code - we break interfaces at will at any time. Practically though it would be a lot of work: Through lib/syncthing types of other packages are exposed, see e.g. [Code search results · GitHub](https://github.com/search?q=repo%3Apixelspark%2Fsushitrain%20syncthing%2Flib&type=code) A bunch of that could be improved, as in expose less in lib/syncthing by moving some of his code as generic helpers to lib/syncthing. However again, it’s a bunch of work.
Moving cmd seems sensible.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [September 10, 2024, 2:31pm UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766/5 "2024-09-10T14:31:31Z")
I’m using Syncthing as a library but I guess I’m prepared to do the necessary conflict resolution when rebasing. If files are mainly moved around this shouldn’t be problematic at all. Otherwise it might be a bit more involved but probably nothing to be afraid of 🙂
> syncthing stays where it is
This makes it sound like there might not even be a conflict at all (for what Syncthing Tray is using at least).
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [September 10, 2024, 2:35pm UTC](https://forum.syncthing.net/t/proposal-rename-some-dirs/22766/6 "2024-09-10T14:35:31Z")
> [@imsodin](#):
>
> c++/syncthingtray afaik does not, that attempt was abandoned.
No, it was not abandoned. (The GNU/Linux packaging is not using it because there it makes more sense to simply depend on the distribution-provided syncthing package. My other builds provide it and I think it makes especially sense under Windows. I also plan to use it for future Android builds.)