Skip to content
This repository has been archived by the owner on Dec 18, 2017. It is now read-only.

Support version ranges in project.json #442

Closed
davidfowl opened this issue Jul 16, 2014 · 13 comments
Closed

Support version ranges in project.json #442

davidfowl opened this issue Jul 16, 2014 · 13 comments

Comments

@davidfowl
Copy link
Member

Today we only support minimum. There should be a way in the future to lock dependency ranges.

@davidfowl davidfowl added this to the Backlog milestone Jul 16, 2014
@davidfowl davidfowl modified the milestones: 1.0.0-rc1, Backlog Jan 10, 2015
@davidfowl davidfowl self-assigned this Jan 10, 2015
davidfowl added a commit that referenced this issue Jan 10, 2015
- Added RequestedVersion to Library as IVersionSpec
- Removed Snapshots from SemanticVersion and added them to
VersionSpec instead.

#442
@muratg muratg modified the milestones: 1.0.0-beta3, 1.0.0-rc1 Jan 14, 2015
@davidfowl
Copy link
Member Author

Initial work is done.

@davidfowl
Copy link
Member Author

In the RC we'll look at implementing syntax similar to https://github.com/npm/node-semver#semver1----the-semantic-versioner-for-npm

@ghost
Copy link

ghost commented Aug 2, 2015

@davidfowl, does this mean we will have support for tilde (~) and circumflex accent (^) etc. like npm in dnx world sometime in future? Is there an issue tracking it?

From npm docs - https://docs.npmjs.com/files/package.json#dependencies:

See semver(7) for more details about specifying version ranges.

  • version Must match version exactly
  • >version Must be greater than version
  • >=version etc
  • <version
  • <=version
  • ~version "Approximately equivalent to version" See semver(7)
  • ^version "Compatible with version" See semver(7)
  • 1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
  • http://... See 'URLs as Dependencies' below
  • * Matches any version
  • "" (just an empty string) Same as *
  • version1 - version2 Same as >=version1 <=version2.
  • range1 || range2 Passes if either range1 or range2 are satisfied.
  • git... See 'Git URLs as Dependencies' below
  • user/repo See 'GitHub URLs' below
  • tag A specific version tagged and published as tag See npm-tag(1)
  • path/path/path See Local Paths below

For example, these are all valid:

{ "dependencies" :
  { "foo" : "1.0.0 - 2.9999.9999"
  , "bar" : ">=1.0.2 <2.1.2"
  , "baz" : ">1.0.2 <=2.3.4"
  , "boo" : "2.0.1"
  , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
  , "asd" : "http://asdf.com/asdf.tar.gz"
  , "til" : "~1.2"
  , "elf" : "~1.2.3"
  , "two" : "2.x"
  , "thr" : "3.3.x"
  , "lat" : "latest"
  , "dyl" : "file:../dyl"
  }
}

URLs as Dependencies

You may specify a tarball URL in place of a version range.

This tarball will be downloaded and installed locally to your package at install time.

Git URLs as Dependencies

Git urls can be of the form:

git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

The commit-ish can be any tag, sha, or branch which can be supplied as an argument to git checkout. The default is master.

GitHub URLs

As of version 1.1.65, you can refer to GitHub urls as just "foo": "user/foo-project". Just as with git URLs, a commit-ish suffix can be included. For example:

{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "visionmedia/express",
    "mocha": "visionmedia/mocha#4727d357ea"
  }
}

Local Paths

As of version 2.0.0 you can provide a path to a local directory that contains a package. Local paths can be saved using npm install --save, using any of these forms:

../foo/bar
~/foo/bar
./foo/bar
/foo/bar

in which case they will be normalized to a relative path and added to your package.json. For example:

{
  "name": "baz",
  "dependencies": {
    "bar": "file:../foo/bar"
  }
}

This feature is helpful for local offline development and creating tests that require npm installing where you don't want to hit an external server, but should not be used when publishing packages to the public registry.

@davidfowl
Copy link
Member Author

It's possible but no promises for v1. NuGet v3 supports putting * anywhere in the version and we'll adopt that logic in dnu so 1.*, 1.0.* will be possible at some point.

@ghost
Copy link

ghost commented Aug 2, 2015

Thanks. The npm folks added every possible option in there. If NuGet and dnx go with the same approach, it may left some corner cases little buggy (hard to test all possibilities without community feedback), but over time reliability can be assured. While going about it the most defensive way as always (hesitate adding new stuff) only slows down such enhancement opportunities IMO.. and it will take ages to get there!

@ptrstpp950
Copy link

@davidfowl what happened with the * in RC. I am just trying to get latest version from feed with *

@davidfowl
Copy link
Member Author

It does not work in the RC. When restore merges with nuget it'll be possible

@ptrstpp950
Copy link

@davidfowl could you explain something more?

@davidfowl
Copy link
Member Author

DNX and DNU are being retired in favor of the dotnet CLI (github.com/dotnet/cli) and nuget. NuGet 3 supports the * syntax in more parts of the version than dnu currently does. We're working on merging the relevant features of DNU back into nuget.

@ptrstpp950
Copy link

@davidfowl do you have use cases in some place written down? Or maybe an open issue with details?

@davidfowl
Copy link
Member Author

For what's exactly? The use of * in nuget?

@ptrstpp950
Copy link

Yes. plus issue to integrate it with DNX an DNU

@davidfowl
Copy link
Member Author

Not sure there's anything specific about *, ask on the nuget repository. You can find other information here https://docs.nuget.org/Consume/ProjectJson-Format#project.json-usage.

DNU NuGet/Home#1588

DNX has nothing to do with NuGet but here is some information on that https://github.com/dotnet/cli/issues/254#issuecomment-158124295

russcam added a commit to elastic/elasticsearch-net that referenced this issue Jan 25, 2016
Needed to move Benchmarking and Profiling projects out of sub-directory Performance as Benchmarking could not locate a reference to Elasticsearch.Net, Nest or Tests projects. Raised an issue to check assumption - aspnet/dnx#3333.
Removed dependency on NDesk.Options and include source file in Benchmarking project.
Benchmarking needs to target dnxcore50 at the moment as it references Tests project.
Update Newtonsoft.Json to 8.0.2. Not clear if there is a way to specify version ranges at present in project.json. See aspnet/dnx#1014 and aspnet/dnx#442. Nuget documentation states lowest version would be selected https://docs.nuget.org/Consume/ProjectJson-Format#project.json-usage
build script Benchmark project now runs DNX solution builds of Benchmarking
Fixed remaining warning
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants