Dandandan commented on pull request #9602: URL: https://github.com/apache/arrow/pull/9602#issuecomment-792286475
@jorgecarleitao I'm perfectly fine with that approach too. I do think that depending on crates that are useful instead of building our own or even duplicating code is what we should do in general, and indeed will benefit others in the Rust community. My reasoning behind my suggestion above was * The crate has no currently no users and (I think) only 1 maintainer. * The code size is small * The PR author is the same as the maintainer of the crate (and I guess it was created for this use case for now?) * It would be easier to review the code / run Miri checks, etc. when it was included in the PR Of course, there might be some other parties that would be interested in `partial_sort` or maybe it will at some point make it to the standard library. Also dependencies have *some* costs, some of them being: * Has some risk that the crated will become unmaintained at some point, but causes a bug / security problem, etc. in Arrow. Or we would like to improve it, but a crate maintainer might be unresponsive. A recent example of this I saw in the `memmap` crate which now has a fork `memmap2` which is quite hard to find as the docs / repo of `memmap` are still online. * Non-semver breaking changes can not be caught in PRs * Build times become larger compared to having the same code in the project (as the crate will be downloaded / compiled separately). Of course one extra small dependency won't matter that much, but it accumulates with lots of dependencies. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
