Move to an org and fork some crates

[NobodyXu]

Upstream jobserver has a longstanding bug relating to lifetime of Client rust-lang/jobserver-rs#25

I submit a solution for fixing this rust-lang/jobserver-rs#40 which unfortunately was rejected due to changing of its interface.

While use of jobserver in cargo-binstall is currently ok and does not trigger the bug, I would still like it to be fixed and the PR I mentioned also improve performance of spawning a new process since it can use posix_spawn on unix (which can use vfork on linux).

[NobodyXu]

I think the way to go is to fork it.
The upstream probably won't have any more release and it will not be actively maintained.

Though I don't want to fork it as a personal project, it would put all burden onto me and increase the bus factor just again.

Maybe we can create an org and put this crate and jobserver into it?

[passcod]

Yeah. That and the github action we were talking about in #229, and probably a separate repo for #246's wrapper would be a good idea.

I have the watchexec org (also where cargo-watch lives, and an increasing number of other crates I keep splitting out) if we want to move over to an existing one to decrease the admin burden, no obligation to maintain anything else in it ofc. Or create a new org.

[NobodyXu]

I think it is better to create a new org, since watchexec is for cargo-watch and anything related to it.

@ryankurte What's your thought on this?

[NobodyXu]

We also need to fork reflinkas it doesn't work on musl targets #260 (comment)

[NobodyXu]

@ryankurte Pinging again in case you missed the last one.

I think we need an orgnisation for cargo-binstall.

[ryankurte]

i'm okay with either way, ideas for an org name if we don't go under watchexec? (we could be slightly more generic to move barely supported things like https://github.com/ryankurte/cargo-debug in the future)

[NobodyXu]

I would like it to be cargo-binstall.

@ryankurte Perhaps something like cargo-subcommands?

[passcod]

• cargo-bins or cargo-bin makes it both a reference to bins as in commands, bins as a binstall, and "a bin" like a box or container.

[NobodyXu]

@passcod That sounds great

[NobodyXu]

@ryankurte I agreed with @passcod 's idea of using cargo-bins.

[NobodyXu]

Upstream jobserver has a longstanding bug relating to lifetime of Client alexcrichton/jobserver-rs#25

I submit a solution for fixing this alexcrichton/jobserver-rs#40 which unfortunately was rejected due to changing of its interface.

While use of jobserver in cargo-binstall is currently ok and does not trigger the bug, I would still like it to be fixed and the PR I mentioned also improve performance of spawning a new process since it can use posix_spawn on unix (which can use vfork on linux).

Regarding this, I figured out that we don't need to use jobserver at all.
We could just use the batch installation feature of cargo-install:

cargo install $crate_name@$version

Though that will not result in parallel compilation of multiple binary crates rust-lang/cargo#9741

@ryankurte I would still want an org because our crate has grown to become reasonably large and needs to extract part of them as separate crates.

[ryankurte]

i've setup cargo-bins and invited y'all / have moved the project there.

forks notwithstanding i would suggest that if we need to split our logic we stick with one repository containing multiple crates rather than introducing maintenance overheads where we don't need em