12

Typically, you have to add something like 

dependencies:
  camera: "^0.2.0"

to the pubspec.yaml file. What happens if I don't include the version number? It's a small thing, but usually, I find a piece of code and want to test it. At the top, I see something like >> 

import 'package:camera/camera.dart';

Do I have to go to the package's homepage to find the version number?

naim5am
  • 1,264
  • 3
  • 17
  • 32

3 Answers3

19

You can use any

dependencies:
  camera: any

Having tighter constraints makes it easier for packages get/packages upgrade to search matching versions because it reduces the solution space, but for simple examples it usually doesn't matter.

pub got an improved solver recently that makes any much less of a problem than it used to be where pub often just timed out when any was used.

Günter Zöchbauer
  • 558,509
  • 191
  • 1,911
  • 1,506
14

as per https://www.dartlang.org/tools/pub/dependencies

Based on what data you want to provide, you can specify dependencies in two ways. The shortest way is to just specify a name:

dependencies:
  transmogrify:

This creates a dependency on transmogrify that allows any version, and looks it up using the default source, which is pub.dartlang.org. To limit the dependency to a range of versions, you can provide a version constraint:

dependencies: transmogrify: ^1.0.0

This creates a dependency on transmogrify using the default source and allowing any version from 1.0.0 to 2.0.0 (but not including 2.0.0). See Version constraints and Caret syntax for details on the version constraint syntax.

I guess that the real answer to my question is that usually, it's best to specify a major version number ratio e.g.: ^1.0.0 == 1.0.0 < 2.0.0. This is to say that this program works and is tested and will keep working with this library dependancy so long as there are no major changes.

naim5am
  • 1,264
  • 3
  • 17
  • 32
3

A version constraint that uses traditional syntax is a series of the following:

any The string any allows any version. This is equivalent to an empty version constraint, but is more explicit. Although any is allowed, we don’t recommend it.

1.2.3

A concrete version number pins the dependency to only allow that exact version. Avoid using this when you can because it can cause version lock for your users and make it hard for them to use your package along with other packages that also depend on it.

>=1.2.3

Allows the given version or any greater one. You’ll typically use this.

>1.2.3

Allows any version greater than the specified one but not that version itself.

<=1.2.3

Allows any version lower than or equal to the specified one. You won’t typically use this.

<1.2.3

Allows any version lower than the specified one but not that version itself. This is what you’ll usually use because it lets you specify the upper version that you know does not work with your package (because it’s the first version to introduce some breaking change).

You can specify version parts as you want, and their ranges are intersected together. For example, '>=1.2.3 <2.0.0' allows any version from 1.2.3 to 2.0.0 excluding 2.0.0 itself. An easier way to express this range is by using caret syntax, or ^1.2.3.

Note: If the > character is in the version constraint, be sure to quote the constraint string, so the character isn’t interpreted as YAML syntax. For example, never use >=1.2.3 <2.0.0; instead, use '>=1.2.3 <2.0.0' or ^1.2.3.

Paresh Mangukiya
  • 37,512
  • 17
  • 201
  • 182