-
Phil de Joux authored
- Adds pijul as type - explicit dot is the same as root - Update doc/cabal-package-description-file.rst - Grammar, comma required for non-restrictive clause - Move warning down the section - Move repository stuff to its own page - Add author and consumer subsections - Keep consistent ordering - Put source-repository before source-repository-package - Reword intro and add hackage linking - A field of this type is always optional - Fix typo - Put the table into the field types section - Link to VCS kind, consistent casing - Introduce the VCS acronym early - Link to cabal get for this|head - Update doc/cabal-package-description-file.rst - Comma after as an example - Update doc/cabal-package-description-file.rst - There are two kinds comma - Split sentences. - Move to how to section - Add version control fields - Rewrite package consumer section - Bump source packages up a level - Rename as "how to source packages" - Rename section, "package source" - Fix whitespace - Mention manual download before cabal download - Use a description list for source-repository fields - Add a warning about the confusing field names - Clarify *source code* ``.tar.gz`` archive - Use Git uppercase - Source Marker section, marks out - Change to "inside a single VCS repository" - Taking a Dependency from a Source Code Repository - Lead with uppercase first letter for Darcs, Git - Fix whitespace - Use lowercase for titles - Change the guide title to "How to get package *source code*". - Hackage is for published, exact versus range of versions - Mention cabal get - Lead with uppercase for Cabal and Hackage - Move VCS fields up in the tree - Mention *source code* in all the section titles - Explain how linking helps contributors and maintainers - Add an example of conversion - Add a dependency vendoring section - Show cloning with cabal build --dry-run - Keep VCS fields small - Add diagrams - Warn about hash in clone folder name - Use code style for .cabal - Use lower caps in title to match other sections - Add missing _ for external link reference - Move package authoring section to last - Use subsections for vendoring - Add a section about publishing - Fix up anchors and references - Typo, "extracts it to a directory" - It is a "``cabal get`` unpacking step" - Use a comma in "Fork, don't vendor" - Add a tag to the src-repo-pkg example - The warning about commits is only for Git repositories - Move note to setting up section - Fix whitespace - Missing source-repository ead in the diff - Use with/without a "-package" suffix ... belongs - Add a reference to cabal get - How to locate and get - Add back the ref to the package consumer section - Replace arrowheads with ASCII - Replace ticked checkboxes with ASCII - Warn about project and the set of pkgs separately - Multiple dependency packages not multiple dependencies - Shorter explanation of vendoring - Lower caps for bold terms - Add references to VCS fields - A marker that points to - Use the shorter "shepherd" - Use grab (not obtain) before obtaining - Clarify terms in source code note - Hackage is only for published package dependencies - Add a link to hackage upload - Add a footnote about packages of a cabal.project - Revert section title to "Specifying the local packages" - Change shepherd to "deal with" - Put source after package, ordering how to guides - Comma after as Co-Authored-By:
Artem Pelenitsyn <a.pelenitsyn@gmail.com> Co-Authored-By:
brandon s allbery kf8nh <allbery.b@gmail.com>
Phil de Joux authored- Adds pijul as type - explicit dot is the same as root - Update doc/cabal-package-description-file.rst - Grammar, comma required for non-restrictive clause - Move warning down the section - Move repository stuff to its own page - Add author and consumer subsections - Keep consistent ordering - Put source-repository before source-repository-package - Reword intro and add hackage linking - A field of this type is always optional - Fix typo - Put the table into the field types section - Link to VCS kind, consistent casing - Introduce the VCS acronym early - Link to cabal get for this|head - Update doc/cabal-package-description-file.rst - Comma after as an example - Update doc/cabal-package-description-file.rst - There are two kinds comma - Split sentences. - Move to how to section - Add version control fields - Rewrite package consumer section - Bump source packages up a level - Rename as "how to source packages" - Rename section, "package source" - Fix whitespace - Mention manual download before cabal download - Use a description list for source-repository fields - Add a warning about the confusing field names - Clarify *source code* ``.tar.gz`` archive - Use Git uppercase - Source Marker section, marks out - Change to "inside a single VCS repository" - Taking a Dependency from a Source Code Repository - Lead with uppercase first letter for Darcs, Git - Fix whitespace - Use lowercase for titles - Change the guide title to "How to get package *source code*". - Hackage is for published, exact versus range of versions - Mention cabal get - Lead with uppercase for Cabal and Hackage - Move VCS fields up in the tree - Mention *source code* in all the section titles - Explain how linking helps contributors and maintainers - Add an example of conversion - Add a dependency vendoring section - Show cloning with cabal build --dry-run - Keep VCS fields small - Add diagrams - Warn about hash in clone folder name - Use code style for .cabal - Use lower caps in title to match other sections - Add missing _ for external link reference - Move package authoring section to last - Use subsections for vendoring - Add a section about publishing - Fix up anchors and references - Typo, "extracts it to a directory" - It is a "``cabal get`` unpacking step" - Use a comma in "Fork, don't vendor" - Add a tag to the src-repo-pkg example - The warning about commits is only for Git repositories - Move note to setting up section - Fix whitespace - Missing source-repository ead in the diff - Use with/without a "-package" suffix ... belongs - Add a reference to cabal get - How to locate and get - Add back the ref to the package consumer section - Replace arrowheads with ASCII - Replace ticked checkboxes with ASCII - Warn about project and the set of pkgs separately - Multiple dependency packages not multiple dependencies - Shorter explanation of vendoring - Lower caps for bold terms - Add references to VCS fields - A marker that points to - Use the shorter "shepherd" - Use grab (not obtain) before obtaining - Clarify terms in source code note - Hackage is only for published package dependencies - Add a link to hackage upload - Add a footnote about packages of a cabal.project - Revert section title to "Specifying the local packages" - Change shepherd to "deal with" - Put source after package, ordering how to guides - Comma after as Co-Authored-By:
Version Control System Fields
=============================
.. _vcs-fields:
Most of the version control system (VCS) fields types are common to both
``source-repository`` and ``source-repository-package`` stanzas.
.. list-table::
:header-rows: 1
:widths: 30 30 40
* - Field Name
- source-repository (head|this)
- source-repository-package
* - type
- [x]
- [x]
* - location
- [x]
- [x]
* - branch
- [x]
- [x]
* - tag
- [x]
- [x]
* - subdir
- [x] (0 or 1)
- [x] (0 or 1 for each dependency)
* - module (CVS only)
- [x]
- [_]
* - post-checkout-command
- [_]
- [x]
.. _vcs-kind:
VCS kind
^^^^^^^^
Cabal supports specifying different information for various common source
control systems. This is the name of the source control system used for a
repository. The currently recognised types are:
- ``darcs``
- ``git``
- ``svn``
- ``cvs``
- ``mercurial`` (or alias ``hg``)
- ``bazaar`` (or alias ``bzr``)
- ``arch``
- ``monotone``
- ``pijul``
The VCS kind will determine what other fields are appropriate to specify for a
particular version control system.
VCS location
^^^^^^^^^^^^
The location of the repository, usually a URL but the exact form of this field
depends on the repository type. For example:
- for Darcs: ``http://code.haskell.org/foo/``
- for Git: ``git://github.com/foo/bar.git``
- for CVS: ``anoncvs@cvs.foo.org:/cvs``
VCS branch
^^^^^^^^^^
Many source control systems support the notion of a branch, as a distinct
concept from having repositories in separate locations. For example CVS, SVN and
git use branches while darcs uses different locations for different branches. If
you need to specify a branch to identify a your repository then specify it in
this field.
VCS tag
^^^^^^^
A tag identifies a particular state of a source repository. The exact form of
the tag depends on the repository type.
VCS subdirectory
^^^^^^^^^^^^^^^^
A field of this type is always optional because it defaults to empty, which
corresponds to the root directory of the repository and is the same as
specifying ``.`` explicitly.
Some projects put the sources for multiple packages inside a single VCS
repository. This field lets you specify the relative path from the root of the
repository to the top directory for the package, i.e. the directory containing
the package's ``.cabal`` file.