Closed FauxFaux closed 5 years ago
Thanks for the pull request!
I'm not sure that I want to merge this given that the 0.14
branch has already split the protocol parts into its own crate (which I think is a more appropriate way of dealing with this). The irc-proto crate even has a tokio feature for enabling or disabling those parts of the code.
Right. I totally failed to understand that development was proceeding like that. I was thinking of making an irc-proto crate myself. I am happy with the alternative crate. Let's try it.
That seems to do exactly what I want, bar fixes that are in develop
but not in 0.14
. Guess I should look at getting 0.14 released.
The main blocker is fewer-allocations
which I was working on in the hopes of finally closing #32, but I'm not convinced that we necessarily need that urgently (or that it wouldn't make the APIs too cumbersome). The other notable thing is restoring some of the stuff that got accidentally wiped out on the 0.14
branch due to a messed up merge (e.g. as noted here).
This PR enables using just the
irc::proto
part of the crate, without building theirc::client
part.This allows dropping >70% of the deps, including
native-tls
which fails horribly to build on anything fun.The changes are noisy, but there are zero logic changes:
()
payloads or just that print "nah"..travis.yml
is already configured to check--no-default-features
, and it passes.I did not make the code warning-clean with
test --no-default-features
, this would (simply!) involve adding morecfg(
everywhere. In my opinion, it is unlikely that it would be possible to move more stuff into the "client" module, to reduce the size of this change. Perhaps the lineproto stuff? Not super relevant.(I'm writing a server-like-thing, if that wasn't obvious.)
Are you willing to carry this feature?