About tilde dependencies

[jean-airoldie]

What is the specific intend behind using tilde dependencies as a default in the repository? As far as I can tell, they don't seem to serve a specific purpose, unless I missed something.

Tilde dependencies are kinda limiting because they prevent minor version bumps that would maintain backward compatibility and theoretically not break your code (however in practice...). I would recommend using caret requirements (e.g. ^1.0.0) as the default to allow the user more flexibility in the choice of dependencies.

I'm trying to depend on this crate but the tilde decencies are quite limiting because it prevents me from using move recent crates that had minor bumps. If you have a specific reason for using tilde dependencies, I'll just maintain a fork, that's fine.

[svartalf]

Hey, @jean-airoldie!

Tilde dependencies are used to reduce potential risk of heim being broken due to one of the dependencies introducing breaking changes in the minor releases (which already happened). I do agree that they are more restrictive and I'm open to arguments about other options, though :)

I'll just maintain a fork, that's fine.

I think you can just use [patch] section to override dependencies instead of maintaining your own fork?

[jean-airoldie]

Tilde dependencies are used to reduce potential risk of heim being broken due to one of the dependencies introducing breaking changes in the minor releases (which already happened). I do agree that they are more restrictive and I'm open to arguments about other options, though :)

That's a fair point. I'm kinda used to getting my code broken also lol. I mean the ideal solution would be to use range dependencies, but that would be more work for you because you would need to periodically check whether a new release works or not. Theoretically even tilde dependencies could not be enough because someone could introduce a breaking change on a patch, but I guess its less likely.

I think you can just use [patch] section to override dependencies instead of maintaining your own fork?

Yeah it works but its more of a pain if you need to patch every single crate that depends transitively on it. Its not like maintaining a fork with a slightly tweaked Cargo.toml is a lot of work.

I guess this is really just a result of cargo being limited to one major version per library, combined with the fact that versioning is not actually enforced and is done on a best effort basis, so mistakes happen. I got my code broken by libc the other day on a minor change, so at this point I've just accepted it.

[jean-airoldie]

I think rust would either need a tool to enforce versioning, or at least a CI tool that can be used to generate ranges of versions that work. Of course, that's really out of the scope of this issue.

I'm ok with closing this issue.

[svartalf]

Well, those are valid points.. I think, considering this and #312, it would be better to switch back to caret versions and be more pricky in the future about used dependencies and what versioning policies they are using.

Let's leave this issue opened till dependencies versioning will be changed.

[fenhl]

I am currently running into this issue as I have a dependency version conflict for the memchr crate, whose version ^2.4.0 is required by regex, while heim-process requires ~2.3. Would you accept a pull request to move to caret dependencies?

[fenhl]

Ah, I see this is already fixed in the repo. Hopefully a release can be published soon.

[dignifiedquire]

@svartalf any chance of another release with the fixed dependencies? I currently have to depend on the github version which I would like to avoid.