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 |