| Index: app/doc/pubspec.markdown
|
| diff --git a/app/doc/pubspec.markdown b/app/doc/pubspec.markdown
|
| deleted file mode 100644
|
| index bb359f9a67e63bd16ba246076e8a26a855b888d8..0000000000000000000000000000000000000000
|
| --- a/app/doc/pubspec.markdown
|
| +++ /dev/null
|
| @@ -1,184 +0,0 @@
|
| ----
|
| -title: "Pubspec Format"
|
| ----
|
| -
|
| -1. [Name](#name)
|
| -1. [Version](#version)
|
| -1. [Description](#description)
|
| -1. [Author/Authors](#authorauthors)
|
| -1. [Homepage](#homepage)
|
| -1. [Documentation](#documentation)
|
| -1. [Dependencies](#dependencies)
|
| -1. [SDK constraints](#sdk-constraints)
|
| -{:.toc}
|
| -
|
| -Every pub package needs some metadata so it can specify its
|
| -[dependencies](glossary.html#dependency). Pub packages that are shared with
|
| -others also need to provide some other information so users can discover them.
|
| -Pub stores this in a file named `pubspec.yaml`, which (naturally) is written in
|
| -the [YAML](http://www.yaml.org/) language.
|
| -
|
| -At the top level are a series of fields. The currently supported ones are:
|
| -
|
| -<dl class="dl-horizontal">
|
| - <dt>Name</dt>
|
| - <dd>Required for every package.</dd>
|
| - <dt>Version</dt>
|
| - <dd>Required for packages that will be hosted on pub.dartlang.org.</dd>
|
| - <dt>Description</dt>
|
| - <dd>Required for packages that will be hosted on pub.dartlang.org.</dd>
|
| - <dt>Author/Authors</dt>
|
| - <dd>Optional.</dd>
|
| - <dt>Homepage</dt>
|
| - <dd>Optional.</dd>
|
| - <dt>Documentation</dt>
|
| - <dd>Optional.</dd>
|
| - <dt>Dependencies</dt>
|
| - <dd>Can be omitted if your package has no dependencies.</dd>
|
| - <dt>Dev dependencies</dt>
|
| - <dd>Can be omitted if your package has no dev dependencies.</dd>
|
| -</dl>
|
| -
|
| -All other fields will be ignored. A simple but complete pubspec looks something
|
| -like this:
|
| -
|
| -{% highlight yaml %}
|
| -name: newtify
|
| -version: 1.2.3
|
| -description: >
|
| - Have you been turned into a newt? Would you like to be? This
|
| - package can help: it has all of the newt-transmogrification
|
| - functionality you've been looking for.
|
| -author: Nathan Weizenbaum <nweiz@google.com>
|
| -homepage: http://newtify.dartlang.org
|
| -documentation: http://docs.newtify.com
|
| -dependencies:
|
| - efts: '>=2.0.4 <3.0.0'
|
| - transmogrify: '>=0.4.0'
|
| -dev_dependencies:
|
| - unittest: '>=0.6.0'
|
| -{% endhighlight %}
|
| -
|
| -## Name
|
| -
|
| -Every package needs a name. When your stellar code gets props on
|
| -the world stage, this is what they'll be hollering. Also, it's how other
|
| -packages will refer to yours, and how it will appear here, should you publish
|
| -it.
|
| -
|
| -It should be all lowercase, with underscores to separate words,
|
| -`just_like_this`. Stick with basic Latin letters and Arabic digits:
|
| -`[a-z0-9_]` and ensure that it's a valid Dart identifier (i.e. doesn't start
|
| -with digits and isn't a reserved word).
|
| -
|
| -Try to pick a name that is clear, terse, and not already in use. A quick search
|
| -[here](/packages) to make sure nothing else is using your name can save you
|
| -heartache later.
|
| -
|
| -## Version
|
| -
|
| -Every package has a version. A version number is required to host your package
|
| -here, but can be omitted for local-only packages. If you omit it, your package
|
| -is implicitly versioned `0.0.0`.
|
| -
|
| -No one really gets excited about versioning, but it's a necessary evil for
|
| -reusing code while letting it evolve quickly. A version number is three numbers
|
| -separated by dots, like `0.2.43`. It can also optionally have a build
|
| -(`+hotfix.oopsie`) or pre-release (`-alpha.12`) suffix.
|
| -
|
| -Each time you publish your package, you will publish it at a specific version.
|
| -Once that's been done, consider it hermetically sealed: you can't touch it
|
| -anymore. To make more changes, you'll need a new version.
|
| -
|
| -When you select a version, follow [semantic versioning][]. When you do, the
|
| -clouds will part and sunshine will pour into your soul. If you don't, prepare
|
| -yourself for hordes of angry users.
|
| -
|
| -[semantic versioning]: http://semver.org
|
| -
|
| -## Description
|
| -
|
| -This is optional for your own personal packages, but if you intend to share
|
| -your package with the world (and you should because, let's be honest with
|
| -ourselves, it's a thing of beauty) you must provide a description. This should
|
| -be relatively short—a few sentences, maybe a whole paragraph—and
|
| -tells a casual reader what they might want to know about your package.
|
| -
|
| -Think of the description as the sales pitch for your package. Users will see it
|
| -when they [browse for packages](/packages). It should be simple plain text:
|
| -no markdown or HTML. That's what your README is for.
|
| -
|
| -## Author/Authors
|
| -
|
| -You're encouraged to use these fields to describe the author(s) of your package
|
| -and provide contact information. `author` should be used if your package has a
|
| -single author, while `authors` should be used with a YAML list if more than one
|
| -person wrote the package. Each author can either be a single name (e.g. `Nathan
|
| -Weizenbaum`) or a name and an email address (e.g. `Nathan Weizenbaum
|
| -<nweiz@google.com>`). For example:
|
| -
|
| -{% highlight yaml %}
|
| -authors:
|
| -- Nathan Weizenbaum <nweiz@google.com>
|
| -- Bob Nystrom <rnystrom@google.com>
|
| -{% endhighlight %}
|
| -
|
| -If anyone uploads your package here, we will show this email address so make
|
| -sure you're OK with that.
|
| -
|
| -## Homepage
|
| -
|
| -This should be a URL pointing to the website for your package. For
|
| -[hosted packages](#hosted-packages), this URL will be linked from the
|
| -package's page. While this is technically optional *please do* provide one. It
|
| -helps users understand where your package is coming from. If nothing else, you
|
| -can always use the URL where you host the source code:
|
| -[GitHub](http://github.com), [code.google.com](http://code.google.com/),
|
| -whatever.
|
| -
|
| -## Documentation
|
| -
|
| -Some packages may have a site that hosts documentation separate from the main
|
| -homepage. If your package has that, you can also add a `documentation:` field
|
| -with that URL. If provided, a link to it will be shown on your package's page.
|
| -
|
| -## Dependencies
|
| -
|
| -<div class="learn-more">
|
| - <a href="/doc/dependencies.html">
|
| - Learn more about dependencies →
|
| - </a>
|
| -</div>
|
| -
|
| -Finally, the pubspec's *raison d'ĂȘtre*: [dependencies](glossary.html#dependency). Here,
|
| -you list each package that your package needs in order to work.
|
| -
|
| -There are two separate sections. Dependencies under `dependencies:` are
|
| -"regular" dependencies. They are packages that anyone using your package will
|
| -also need. Dependencies under `dev_dependencies` are
|
| -[dev dependencies](glossary.html#dev-dependency). These are packages that are
|
| -only needed in the development of your package itself.
|
| -
|
| -## SDK constraints
|
| -
|
| -A package can indicate which versions of its dependencies it supports, but there
|
| -is also another implicit dependency all packages have: the Dart SDK itself.
|
| -Since the Dart platform evolves over time, a package may only work with certain
|
| -versions of it.
|
| -
|
| -A package can specify that using an *SDK constraint*. This goes inside a
|
| -separate top-level "environment" field in the pubspec and uses the same
|
| -[version constraint](dependencies.html#version-constraints) syntax as
|
| -dependencies. For example, this constraint says that this package works with any
|
| -Dart SDK from 0.3.4 or later:
|
| -
|
| -{% highlight yaml %}
|
| -environment:
|
| - sdk: ">=0.3.4"
|
| -{% endhighlight %}
|
| -
|
| -Pub will try to find the latest version of a package whose SDK constraint works
|
| -with the version of the Dart SDK that you have installed.
|
| -
|
| -[pubsite]: http://pub.dartlang.org
|
| -[semantic versioning]: http://semver.org/
|
|
|