-
Notifications
You must be signed in to change notification settings - Fork 21
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
Disband collect-rs in favour of separate crates? #138
Comments
So, the breakage should be halting in the not-so-distant future. But if you feel like you need more focus, that could be a good reason to break things up. I do think it's really worthwhile to try to keep some group efforts going, and in particular it'd be nice to have some means of "staging" collections and utils around them for eventual |
Another possible option for the immediate future would be to have many crates inside of this one repository. Each would be published separately, but the management and group effort could stay centralized around this repository. I do somewhat agree that a crate-per-collection may be a good way forward here. |
I'd also note I'm getting a bit burnt out on collection code-review, which I find much more intensive than reviewing other kinds of changes. It's subtle, complicated, and often brushes up against Having some kind of... club...(?) of people interested in working on collections stuff could be a good idea. You have a collection design, you want someone to review it, you ping the club. |
I'm totally in agreement. For any one person, there only tends to be a few modules they care about. I found myself burnt out on data structures review too. A club sounds fun. Can we get t-shirts? |
I approve, but I really appreciate the group maintenance and conventions effort which is much harder with many disparate crates and authors and I would be sad to lose it. We should figure out a good way to keep working together. |
I also approve, though there is definitely value in enforcing conventions and upkeep through a single repo. A GitHub organization might be useful. |
I have made https://github.com/contain-rs (shout-outs to cmr for the fantastic pun). |
Crates to make:
|
Good progress today. CC @stepancheg @sellibitze @csouth3 @csherratt This is happening, your code is moving/moved. |
Thanks for the all the hard work, @gankro et al! This issue has slipped my attention until you mentioned my name. But I agree with everything that's been said here. |
@huonw has set up highfive and homu for us under the @FlashCat bot: Of particular interest: http://huon.me:54857/queue/all |
Thanks for the heads up Gankro, everything looks great to me here! |
@reem Modulo bugs, yes. See contain-rs/linked-hash-map#2 for my experiments with using the functionality. Basically if you r+ it seems to get stuck in an infinite verification step. Not sure what exactly what went wrong. Maybe @barosl has an idea. |
I've made stub repos for linear-map, par-vec, and string-joiner. If someone wants to take any of those migrations over, that would be super keen. Otherwise I'm kinda unsure what to do with immut-slist and tree-map. See #152 for immut-slist. immut is a weird name/convention to eternalize in a crate name. Then again immut-slist is mostly a proof-of-concept. See #137 for tree-map. Basically we have a tricky naming/conventions issue. When we migrated trie-map we renamed it to trie, and actually renamed the collections to Map and Set so that you have trie::Map and trie::Set. But @apasel422 scooped tree in crates.io for his experimental replacement. |
Hmm. It may make more sense to have separate crates for maps and sets after all, mainly because |
|
@huonw Sounds like something that might use mutexes or some lock-free strategy to be mutably shared, where this is persistent. |
Maybe we should group persistent collections together? I feel like we'd just get into the same situation as with collect down the line though. |
I think I fixed it: contain-rs/blist#1 (comment) Basically a problem with how travis handles organisations. (tl;dr: fix: activate travis in new repos via @FlashCat's account.)
I don't have that sense ("shared" == |
@gankro I can migrate |
@cybergeek94 That would be great! Check out any of the other repos for the format we're using. |
@gankro Just curious, what would be the procedure to propose a new crate to the group? |
@cybergeek94 I think we're looking at https://github.com/contain-rs/discuss ala rust-lang/rfcs right now |
@gankro Yeah I saw that not long after I sent the previous message. I'm looking at the |
Ah! I'll make a dummy README |
dummy'd |
@gankro: Another crate name option for migrating |
string_joiner and linear_map are all that's left |
I'd like to move |
@tbu- I've pushed up a dummy repo you can make a PR against. https://github.com/contain-rs/linear-map Check out https://github.com/contain-rs/blist for an example migration (basically just copy the src file to be lib.rs, add the copyright header, fix the cargo.toml, fix the README, and fix feature-flags/externs. |
I've also pushed a dummy repo for string-joiner and set up (I think) the last of the gh-pages and travis stuff. |
Whoops, string-joiner still hasn't been migrated! |
We're constantly getting winged and whammed by some weird language change breaking some thing we're doing. The whole crate's kinda unfocused and we've got all these cargo features to paper over the fact that we're really a collection of distinct crates. Meanwhile the cargo ecosystem seems to really favour "just do this one thing" crates.
The main downside I see is that this loses us the group maintenance effect.
Thoughts?
@aturon @alexcrichton @cgaebel @apasel422 @reem @huonw
The text was updated successfully, but these errors were encountered: