Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(7)

Unified Diff: app/doc/pubspec.markdown

Issue 162403002: Remove docs and point to ones on dartlang.org. (Closed) Base URL: https://github.com/dart-lang/pub-dartlang.git@master
Patch Set: Re-upload. Created 6 years, 10 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
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&mdash;a few sentences, maybe a whole paragraph&mdash;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 &rarr;
- </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/

Powered by Google App Engine
This is Rietveld 408576698