collect-rs
collect-rs copied to clipboard
Gankra
Disband collect-rs in favour of separate crates?
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
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 std inclusion, but you could consider having a github organization or some such for doing that.
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 unsafe (unclear semantics and all). Not having a central repo would relieve a bit of the pressure as people can just make their whatever collection crates and I'm not blocking them from making changes or landing their latest whatevermajig.
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:
- [x] compare (done, unpublished atm, not sure about crate naming/ownership story)
- [x] tree (should map and set be separate crates...?)
- [x] trie (should map and set be separate crates...?)
- [x] interval_heap
- [x] linked_hash_map
- [x] lru_cache
- [x] blist
- [x] enum_set
- [x] immut_slist
- [x] linked_list (currently proto::DList)
- [x] linear_map
- [x] par_vec
- [x] ordered_iter
- [ ] string_joiner
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:
http://huon.me:54857/
Of particular interest: http://huon.me:54857/queue/all
@Gankro that's awesome. So we should mark PRs using @FlashCat instead of @bors, and it'll work like in rust-lang?
@reem Modulo bugs, yes. See https://github.com/contain-rs/linked-hash-map/pull/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 tree doesn't really mean anything on its own. For example, if the standard library's HashMap were split into its own crate, I wouldn't expect it to be called hash, necessarily.
@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.
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 think I fixed it: https://github.com/contain-rs/blist/pull/1#issuecomment-83440529 Basically a problem with how travis handles organisations. (tl;dr: fix: activate travis in new repos via @FlashCat's account.)
Sounds like something that might use mutexes or some lock-free strategy to be mutably shared, where this is persistent.
I don't have that sense ("shared" == Rc and Arc for me), but I suppose persistent-slist is another possibility too.
@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 par_vec repo and it looks like I can't fork it or submit PRs while it's empty. How should I proceed?
@Gankro: Another crate name option for migrating {TreeMap, TreeSet} is simply bst, with the types being moved to bst::{Map, Set}.
@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.