building this project is problematic for downstreams
Opened this issue · 1 comments
Hi! 👋
When trying to build this project I noticed, that a few anti-patterns are used, which make it hard for downstreams to package this software.
To my knowledge Debian will require, that the asdf crate is available on crates.io, as they use the service for discovery and sources. It seems asdf is namesquatted though and a different name should be chosen and the crates should be released on crates.io.
The use of gitsubmodules is an anti-pattern (as workspaces exist) and since there are no combined source tarballs available, this forces all downstreams to use git when building. Please use workspaces or depend on the asdfspline as a crate.
For now, I'm only using the C API, so I don't need the package on crates.io. If anyone actually needs that, I might put it there.
I don't even know if/how it would be possible to build this with cargo-c when the data is on crates.io. Maybe one would first have to manually download and unpack the crate?
Are there any existing packages that use cargo-c so we could have a look how it is done there?
Would there be separate packages for a Rust crate and for its C API?
this forces all downstreams to use git when building
Is that a problem?
I thought all packaging systems support Git by now?
It was quite straightforward to create a package (containing only the C API) for brew: https://github.com/SoundScapeRenderer/homebrew-ssr/blob/main/Formula/asdf.rb
I wouldn't even know how to do that via crates.io.