| OLD | NEW |
| (Empty) |
| 1 --- | |
| 2 title: "Getting Started" | |
| 3 --- | |
| 4 | |
| 5 1. [Installing and configuring pub](#installing-and-configuring-pub) | |
| 6 1. [Creating a package](#creating-a-package) | |
| 7 1. [Adding a dependency](#adding-a-dependency) | |
| 8 1. [Getting dependencies](#getting-dependencies) | |
| 9 1. [Importing code from a dependency](#importing-code-from-a-dependency) | |
| 10 1. [Upgrading a dependency](#upgrading-a-dependency) | |
| 11 1. [Publishing a package](#publishing-a-package) | |
| 12 {:.toc} | |
| 13 | |
| 14 *Pub* is a package manager for Dart. It helps you reuse existing Dart code | |
| 15 and bundle your Dart apps and libraries so that you can reuse and share them | |
| 16 with other people. Pub handles versioning and dependency management so that you | |
| 17 can ensure that your app runs on other machines exactly the same as it does on | |
| 18 yours. | |
| 19 | |
| 20 To **find** a package that's on pub.dartlang.org, | |
| 21 use the Search box at the top right of this page. | |
| 22 | |
| 23 To **use** a package that's on pub.dartlang.org: | |
| 24 | |
| 25 1. Create a `pubspec.yaml` file | |
| 26 (if one doesn't already exist) | |
| 27 and list the package as dependency. | |
| 28 For example, to use the [web_ui](/packages/web_ui) package | |
| 29 in an app, put this in a top-level file named `pubspec.yaml`: | |
| 30 | |
| 31 name: my_app | |
| 32 dependencies: | |
| 33 web_ui: any | |
| 34 | |
| 35 1. Run `pub get`, either on the command line | |
| 36 or through the Dart Editor menu: Tools > Pub Get. | |
| 37 | |
| 38 1. Import one or more libraries from the package: | |
| 39 | |
| 40 import 'package:web_ui/web_ui.dart'; | |
| 41 | |
| 42 For details and pointers to more documentation, read on. | |
| 43 | |
| 44 ## Installing and configuring pub | |
| 45 | |
| 46 Pub is in the [Dart SDK](http://www.dartlang.org/docs/sdk/), | |
| 47 which you can download by itself or as part of | |
| 48 [Dart Editor](http://www.dartlang.org/docs/editor/). | |
| 49 You can use pub through | |
| 50 [Dart Editor](http://www.dartlang.org/docs/editor/), or through the | |
| 51 `pub` command-line app, which lives inside the `bin` directory of the Dart SDK. | |
| 52 | |
| 53 To use pub and other tools on the command line, | |
| 54 you might want to add the SDK's `bin` directory to your system path. | |
| 55 For example, on Mac and Linux: | |
| 56 | |
| 57 export PATH=$PATH:<path to sdk>/bin | |
| 58 | |
| 59 For Windows, here's an equivalent in PowerShell: | |
| 60 | |
| 61 [Environment]::SetEnvironmentVariable("PATH", "$env:PATH;<path to sdk>\bin",
"User") | |
| 62 | |
| 63 In the examples above, `<path to sdk>` is the absolute path | |
| 64 to the main directory of the SDK. For example, | |
| 65 if you install Dart Editor in | |
| 66 `/home/me/dart`, then add this to your PATH: | |
| 67 | |
| 68 /home/me/dart/dart-sdk/bin | |
| 69 | |
| 70 On Windows, you can also set the system PATH environment variable through the | |
| 71 Control Panel. A quick | |
| 72 [search](https://www.google.com/search?q=windows+set+environment+variable) | |
| 73 should find the instructions for your version of Windows. | |
| 74 | |
| 75 ## Creating a package | |
| 76 | |
| 77 <div class="learn-more"> | |
| 78 <a href="/doc/package-layout.html"> | |
| 79 Learn more about packages → | |
| 80 </a> | |
| 81 </div> | |
| 82 | |
| 83 A **package** in pub is a directory that contains Dart code and any other stuff | |
| 84 that goes along with it like resources, tests, and docs. Frameworks and | |
| 85 reusable libraries are obviously packages, but applications are too. If your | |
| 86 app wants to use pub packages, it needs to be a package too. | |
| 87 | |
| 88 While everything is a package in pub, there are two flavors of packages that are | |
| 89 used slightly differently in practice. A [**library | |
| 90 package**](glossary.html#library-package) is a package that is intended to be | |
| 91 reused by other packages. It will usually have code that other packages import, | |
| 92 and it will likely be hosted somewhere that people can get to. An [**application | |
| 93 package**](glossary.html#application-package) only *consumes* packages but | |
| 94 doesn't itself get reused. In other words, library packages will be used as | |
| 95 dependencies, but application packages won't. | |
| 96 | |
| 97 In most cases, there's no difference between the two and we'll just say | |
| 98 "package". In the few places where it does matter, we'll specify "library | |
| 99 package" or "application package". | |
| 100 | |
| 101 <div class="learn-more"> | |
| 102 <a href="/doc/pubspec.html"> | |
| 103 Learn more about pubspecs → | |
| 104 </a> | |
| 105 </div> | |
| 106 | |
| 107 To turn your app into an application package so it can use other packages, you | |
| 108 just need to give it a **pubspec**. This file is written using the | |
| 109 [YAML language](http://yaml.org) and is named `pubspec.yaml`. The simplest | |
| 110 possible pubspec just contains the name of the package. Save the pubspec file as | |
| 111 `pubspec.yaml` in the root directory of your app. | |
| 112 | |
| 113 Behold, the simplest possible `pubspec.yaml`: | |
| 114 | |
| 115 {% highlight yaml %} | |
| 116 name: my_app | |
| 117 {% endhighlight %} | |
| 118 | |
| 119 Now `my_app` is a pub package! | |
| 120 | |
| 121 ## Adding a dependency | |
| 122 | |
| 123 <div class="learn-more"> | |
| 124 <a href="/doc/dependencies.html"> | |
| 125 Learn more about dependencies → | |
| 126 </a> | |
| 127 </div> | |
| 128 | |
| 129 One of pub's main jobs is managing **dependencies**. A dependency is just | |
| 130 another package that your package relies on. If your app is using some | |
| 131 transformation library called "transmogrify", then your app package will depend | |
| 132 on the `transmogrify` package. | |
| 133 | |
| 134 You specify your package's dependencies in the pubspec file immediately after | |
| 135 your package name. For example: | |
| 136 | |
| 137 {% highlight yaml %} | |
| 138 name: my_app | |
| 139 dependencies: | |
| 140 transmogrify: | |
| 141 {% endhighlight %} | |
| 142 | |
| 143 Here, we are declaring a dependency on the (fictional) `transmogrify` package. | |
| 144 | |
| 145 ## Getting dependencies | |
| 146 | |
| 147 <div class="learn-more"> | |
| 148 <a href="/doc/pub-get.html"> | |
| 149 Learn more about <tt>pub get</tt> → | |
| 150 </a> | |
| 151 </div> | |
| 152 | |
| 153 Once you've declared a dependency, you then tell pub to get it for you. If | |
| 154 you're using the Editor, select "Pub Get" from the "Tools" menu. If you're | |
| 155 rocking the command line, do: | |
| 156 | |
| 157 $ cd path/to/your_app | |
| 158 $ pub get | |
| 159 | |
| 160 <aside class="alert alert-warning"> | |
| 161 Today, this command must be run from the directory containing | |
| 162 <tt>pubspec.yaml</tt>. In the future, you will be able to run it from any | |
| 163 sub-directory of the package. | |
| 164 </aside> | |
| 165 | |
| 166 When you do this, pub will create a `packages` directory in the same directory | |
| 167 as `pubspec.yaml`. In there, it will place each package that your package | |
| 168 depends on (these are called your **immediate dependencies**). It will also | |
| 169 look at all of those packages and get everything *they* depend on, recursively | |
| 170 (these are your **transitive dependencies**). | |
| 171 | |
| 172 When this is done, you will have a `packages` directory that contains every | |
| 173 single package your program needs in order to run. | |
| 174 | |
| 175 ## Importing code from a dependency | |
| 176 | |
| 177 Now that you have a dependency wired up, you want to be able to use code from | |
| 178 it. To access a library in a another package, you will import it using the | |
| 179 `package:` scheme: | |
| 180 | |
| 181 {% highlight dart %} | |
| 182 import 'package:transmogrify/transmogrify.dart'; | |
| 183 {% endhighlight %} | |
| 184 | |
| 185 This looks inside the `transmogrify` package for a top-level file named | |
| 186 `transmogrify.dart`. Most packages just define a single entrypoint whose name | |
| 187 is the same as the name of the package. Check the documentation for the package | |
| 188 to see if it exposes anything different for you to import. | |
| 189 | |
| 190 <aside class="alert alert-info"> | |
| 191 This works by looking inside the generated <tt>packages</tt> directory. If you | |
| 192 get an error, the directory may be out of date. Fix it by running | |
| 193 <tt>pub get</tt> whenever you change your pubspec. | |
| 194 </aside> | |
| 195 | |
| 196 You can also use this style to import libraries from within your own package. | |
| 197 For example, let's say your package is laid out like: | |
| 198 | |
| 199 transmogrify/ | |
| 200 lib/ | |
| 201 transmogrify.dart | |
| 202 parser.dart | |
| 203 test/ | |
| 204 parser/ | |
| 205 parser_test.dart | |
| 206 | |
| 207 The `parser_test` file *could* import `parser.dart` like this: | |
| 208 | |
| 209 {% highlight dart %} | |
| 210 import '../../lib/parser.dart'; | |
| 211 {% endhighlight %} | |
| 212 | |
| 213 But that's a pretty nasty relative path. If `parser_test.dart` is ever moved | |
| 214 up or down a directory, that path will break and you'll have to fix the code. | |
| 215 Instead, you can do: | |
| 216 | |
| 217 {% highlight dart %} | |
| 218 import 'package:transmogrify/parser.dart'; | |
| 219 {% endhighlight %} | |
| 220 | |
| 221 This way, the import can always get to `parser.dart` regardless of where the | |
| 222 importing file is. | |
| 223 | |
| 224 <!-- TODO(rnystrom): Enable this when that doc exists. | |
| 225 <div class="learn-more"> | |
| 226 <a href="/doc/package-scheme.html"> | |
| 227 Learn more about the <tt>package:</tt> scheme | |
| 228 <i class="icon-hand-right icon-white"> </i> | |
| 229 </a> | |
| 230 </div> | |
| 231 --> | |
| 232 | |
| 233 ## Upgrading a dependency | |
| 234 | |
| 235 <div class="learn-more"> | |
| 236 <a href="/doc/pub-upgrade.html"> | |
| 237 Learn more about <tt>pub upgrade</tt> → | |
| 238 </a> | |
| 239 </div> | |
| 240 | |
| 241 The first time you get a new dependency for your package, pub will download the | |
| 242 latest version of it that's compatible with your other dependencies. It then | |
| 243 locks your package to *always* use that version by creating a **lockfile**. | |
| 244 This is a file named `pubspec.lock` that pub creates and stores next to your | |
| 245 pubspec. It lists the specific versions of each dependency (immediate and | |
| 246 transitive) that your package uses. | |
| 247 | |
| 248 If this is an application package, you will check this file into source control. | |
| 249 That way, everyone hacking on your app ensures they are using the same versions | |
| 250 of all of the packages. This also makes sure you use the same versions of stuff | |
| 251 when you deploy your app to production. | |
| 252 | |
| 253 When you are ready to upgrade your dependencies to the latest versions, do: | |
| 254 | |
| 255 $ pub upgrade | |
| 256 | |
| 257 This tells pub to regenerate the lockfile using the newest available versions of | |
| 258 your package's dependencies. If you only want to upgrade a specific dependency, | |
| 259 you can specify that too: | |
| 260 | |
| 261 $ pub upgrade transmogrify | |
| 262 | |
| 263 This upgrades `transmogrify` to the latest version but leaves everything else | |
| 264 the same. | |
| 265 | |
| 266 ## Publishing a package | |
| 267 | |
| 268 <div class="learn-more"> | |
| 269 <a href="/doc/pub-lish.html"> | |
| 270 Learn more about <tt>pub publish</tt> → | |
| 271 </a> | |
| 272 </div> | |
| 273 | |
| 274 Pub isn't just for using other people's packages. It also allows you to share | |
| 275 your packages with the world. Once you've written some useful code and you want | |
| 276 everyone else to be able to use it, just run: | |
| 277 | |
| 278 $ pub publish | |
| 279 | |
| 280 Pub will check to make sure that your package follows the [pubspec | |
| 281 format](pubspec.html) and [package layout conventions](package-layout.html), and | |
| 282 then upload your package to [pub.dartlang.org](http://pub.dartlang.org). Then | |
| 283 any Pub user will be able to download it or depend on it in their pubspecs. For | |
| 284 example, if you just published version 1.0.0 of a package named `transmogrify`, | |
| 285 then they can write: | |
| 286 | |
| 287 {% highlight yaml %} | |
| 288 dependencies: | |
| 289 transmogrify: ">= 1.0.0 < 2.0.0" | |
| 290 {% endhighlight %} | |
| 291 | |
| 292 Keep in mind that publishing is forever. As soon as you publish your awesome | |
| 293 package, users will be able to depend on it. Once they start doing that, | |
| 294 removing the package would break theirs. To avoid that, pub strongly discourages | |
| 295 deleting packages. You can always upload new versions of your package, but old | |
| 296 ones will continue to be available for users that aren't ready to upgrade yet. | |
| OLD | NEW |