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

Add optional "minimum required versions" to smackspec requires, use it to install packages faster #4

Open
robsimmons opened this issue Oct 24, 2011 · 4 comments

Comments

@robsimmons
Copy link
Member

In addition to the existing smackspec syntax

require: cmlib v3

which specifies that the user will only refer to "v3", it would be helpful to have a "minimum" syntax, like this:

require: cmlib v3 (v3.19.12)

which says that v3 will satisfy their constraints, but that it must be at least v3.19.12 (this only makes sense when the constraint - v3 in this case - satisfies the minimal version - v3.19.12 in this case). This is the same as the common semantic version constraint pattern "<4.0.0 >=3.19.12" seen in other tools.

Once this syntax was in place, the "resolve dependencies" code could be made slightly more complicated in order to notice the case where, while 3.19.12 is required and 3.30.0 is available, 3.24.4 is already installed in the system, so there's no need to get the most recent version.

@Ahnfelt
Copy link
Contributor

Ahnfelt commented Oct 24, 2011

Perhaps since we're using semantic versioning,

requires: cmlib 3.19.12

should always mean

requires: cmlib >=3.19.12 <4.0.0

If the semantic versioning is followed perfectly, then all later versions with the same major version number should be compatible.

This may require the addition of equality constraints for those cases where semantic versioning wasn't followed, eg.

requires: cmlib ==3.19.12

@robsimmons
Copy link
Member Author

My thought about the current design is that the thing you write after requires: cmlib (either v1 or v1.3 or v1.3.5) is connected to the file path that you use to access cmlib, so if you write v1.3, you don't care if smackage, behind the scenes, deletes v1.3.5 and replaces it with v1.3.6, but that if v1.5.7 gets installed you expect some variant of v1.3 to stick around. That's been my rationale all along for having a single specific constraint like v1.

@Ahnfelt
Copy link
Contributor

Ahnfelt commented Oct 24, 2011

That makes sense; I guess I'm still thinking in Hackage terms.

@robsimmons
Copy link
Member Author

One of the many things done in commit 50e816a was to add this syntax, which can support the short-cut install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants