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

Provide features to import parts of the crate #42

Open
gendx opened this issue Apr 28, 2020 · 3 comments
Open

Provide features to import parts of the crate #42

gendx opened this issue Apr 28, 2020 · 3 comments

Comments

@gendx
Copy link
Owner

gendx commented Apr 28, 2020

For now, dependents of lzma-rs import all of LZMA, LZMA2 and XZ, even if they only need LZMA for example. This could lead to unnecessary dependencies if for example SHA-256 checksums are added for the XZ layer (#32).

In the next breaking release, the code could be split with Cargo features:

  • by default, lzma is available,
  • the lzma2 feature enables lzma2 on top of it,
  • the xz feature enables all of lzma, lzma2 and xz,
  • the sha256 feature enables support for SHA-256 checksums (instead of returning an Err) - only relevant for xz.
@gendx
Copy link
Owner Author

gendx commented Jul 16, 2020

  • The enable_logging feature shouldn't bring the env_logger dependency - env_logger should be a dev-dependency only.

@chyyran
Copy link
Contributor

chyyran commented Jun 1, 2022

This doesn't need to be a breaking release if default imports everything. It would be an opt-out rather than opt-in but can be done without a major version increment.

Might I also suggest having encode being it's own feature as well?

@gendx
Copy link
Owner Author

gendx commented Jun 5, 2022

This doesn't need to be a breaking release if default imports everything. It would be an opt-out rather than opt-in but can be done without a major version increment.

If something already depends on lzma-rs with default-features = false, it would break them. So this is a breaking change. But given that lzma-rs is still not stable (currently version 0.2.0), I think that it's totally fine to increment the major version (i.e. 0.3.x).

Might I also suggest having encode being it's own feature as well?

Sounds good, especially given that the current implementation doesn't try to compress much (see #9).

@gendx gendx added this to the First stable release (1.0.0) milestone Sep 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants