[BUG] Naming of module on case-insensitive filesystems

[v-starodubov]

Version of orchestrion
Latest version (0.8.1)

Describe what happened:
On MacOS, installing go install github.com/datadog/orchestrion@latest and then go mod vendor putting to orchestrion to vendor/github.com/DataDog instead of vendor/github.com/datadog, because others packets in dependency installs as github.com/DataDog/...

$ ls -la vendor/github.com/DataDog
drwxr-xr-x   11 v.starodubov  staff   352 Sep 20 22:08 .
drwxr-xr-x  172 v.starodubov  staff  5504 Sep 20 22:08 ..
drwxr-xr-x    8 v.starodubov  staff   256 Sep 20 22:08 appsec-internal-go
drwxr-xr-x    3 v.starodubov  staff    96 Sep 20 22:08 datadog-agent
drwxr-xr-x    3 v.starodubov  staff    96 Sep 20 22:08 datadog-go
drwxr-xr-x    3 v.starodubov  staff    96 Sep 20 22:08 go-libddwaf
drwxr-xr-x   10 v.starodubov  staff   320 Sep 20 22:08 go-sqllexer
drwxr-xr-x    9 v.starodubov  staff   288 Sep 20 22:08 go-tuf
drwxr-xr-x   11 v.starodubov  staff   352 Sep 20 22:08 gostackparse
drwxr-xr-x   18 v.starodubov  staff   576 Sep 20 22:08 orchestrion
drwxr-xr-x    6 v.starodubov  staff   192 Sep 20 22:08 sketches-go

$ ls -la vendor/github.com/datadog
drwxr-xr-x   11 v.starodubov  staff   352 Sep 20 22:08 .
drwxr-xr-x  172 v.starodubov  staff  5504 Sep 20 22:08 ..
drwxr-xr-x    8 v.starodubov  staff   256 Sep 20 22:08 appsec-internal-go
drwxr-xr-x    3 v.starodubov  staff    96 Sep 20 22:08 datadog-agent
drwxr-xr-x    3 v.starodubov  staff    96 Sep 20 22:08 datadog-go
drwxr-xr-x    3 v.starodubov  staff    96 Sep 20 22:08 go-libddwaf
drwxr-xr-x   10 v.starodubov  staff   320 Sep 20 22:08 go-sqllexer
drwxr-xr-x    9 v.starodubov  staff   288 Sep 20 22:08 go-tuf
drwxr-xr-x   11 v.starodubov  staff   352 Sep 20 22:08 gostackparse
drwxr-xr-x   18 v.starodubov  staff   576 Sep 20 22:08 orchestrion
drwxr-xr-x    6 v.starodubov  staff   192 Sep 20 22:08 sketches-go

If run same set of commands on Ubuntu 20.04, these locations will be separated:

$ ls -la vendor/github.com/DataDog
drwxrwxr-x  10 jenkins jenkins 4096 Sep 20 22:16 .
drwxrwxr-x 173 jenkins jenkins 4096 Sep 20 22:16 ..
drwxrwxr-x   7 jenkins jenkins 4096 Sep 20 22:16 appsec-internal-go
drwxrwxr-x   3 jenkins jenkins 4096 Sep 20 22:16 datadog-agent
drwxrwxr-x   3 jenkins jenkins 4096 Sep 20 22:16 datadog-go
drwxrwxr-x   3 jenkins jenkins 4096 Sep 20 22:16 go-libddwaf
drwxrwxr-x   2 jenkins jenkins 4096 Sep 20 22:16 go-sqllexer
drwxrwxr-x   8 jenkins jenkins 4096 Sep 20 22:16 go-tuf
drwxrwxr-x   2 jenkins jenkins 4096 Sep 20 22:16 gostackparse
drwxrwxr-x   3 jenkins jenkins 4096 Sep 20 22:16 sketches-go

$ ls -la vendor/github.com/datadog
drwxrwxr-x   3 jenkins jenkins 4096 Sep 20 22:16 .
drwxrwxr-x 173 jenkins jenkins 4096 Sep 20 22:16 ..
drwxrwxr-x   4 jenkins jenkins 4096 Sep 20 22:16 orchestrion

If orchestrion is on the same system where it was installed, everything is working, but when moving between systems (developer working on MacOS, but compiling app on Ubuntu with Jenkins), there are problems with linking.

$ go install github.com/DataDog/orchestrion@latest
go: github.com/DataDog/orchestrion@latest: version constraints conflict:
        github.com/DataDog/[email protected]: parsing go.mod:
        module declares its path as: github.com/datadog/orchestrion
                but was required as: github.com/DataDog/orchestrion

Describe what you expected:
Consistent path naming between DataDog modules:

go install github.com/DataDog/orchestrion@latest

Steps to reproduce the issue:

1. Run command on case-insensitive filesystem

$ go install github.com/datadog/orchestrion@latest
$ go mod vendor

Push code to case-sensitive filesystem, try to run orchestrion go .... Then run go mod vendor and then look at file structure at vendor/github.com

Additional environment details (Version of Go, Operating System, etc.):
Go 1.22.6
MacOS Sequoia 15.0, APFS filesystem (not case-sensitive or encrypted)
Ubuntu 20.04.6 LTS, ext4 filesystem

[RomainMuller]

This does feel like an issue where go mod vendor does not behave the way it should... I would have expected the vendoring directory for those DataDog entries to be !data!dog directories. In fact, there is an open issue on the golang/go repository (golang/go#38342) about this, but it has been open for a long while and sounds like there is a lot of debate on how to fix this without breaking GOPATH support.

TL;DR - It sounds like the best course of action would be to rename the root import path to use the more common captialized version; although I'm not extremely fond of making that breaking change (changing all other DataDog modules to use datadog would be practically intractible).