Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to an org and fork some crates #251

Closed
NobodyXu opened this issue Jul 27, 2022 · 12 comments
Closed

Move to an org and fork some crates #251

NobodyXu opened this issue Jul 27, 2022 · 12 comments
Labels
Blocked: upstream Fix or feature is needed to be implemented upstream (in a dependency) help wanted Extra attention is needed

Comments

@NobodyXu
Copy link
Member

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 NobodyXu added help wanted Extra attention is needed Blocked: upstream Fix or feature is needed to be implemented upstream (in a dependency) labels Jul 27, 2022
@NobodyXu
Copy link
Member Author

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
Copy link
Member

passcod commented Jul 27, 2022

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
Copy link
Member Author

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 NobodyXu mentioned this issue Jul 30, 2022
@passcod passcod changed the title Tracking jobserver lifetime bug Move to an org and fork some crates Jul 30, 2022
@NobodyXu
Copy link
Member Author

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

@NobodyXu
Copy link
Member Author

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

I think we need an orgnisation for cargo-binstall.

@ryankurte
Copy link
Collaborator

ryankurte commented Aug 3, 2022

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
Copy link
Member Author

NobodyXu commented Aug 3, 2022

I would like it to be cargo-binstall.

@ryankurte Perhaps something like cargo-subcommands?

@passcod
Copy link
Member

passcod commented Aug 3, 2022

  • 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
Copy link
Member Author

NobodyXu commented Aug 3, 2022

@passcod That sounds great

@NobodyXu
Copy link
Member Author

NobodyXu commented Aug 3, 2022

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

@NobodyXu
Copy link
Member Author

NobodyXu commented Aug 3, 2022

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
Copy link
Collaborator

ryankurte commented Aug 4, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocked: upstream Fix or feature is needed to be implemented upstream (in a dependency) help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants