You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

remote-pkgs.rst 7.8KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231
  1. Remote Packages and Repositories
  2. ################################
  3. .. highlight:: bash
  4. ``dds`` stores a local database of available packages, along with their
  5. dependency statements and information about how a source distribution thereof
  6. may be obtained.
  7. Inside the database are *package repositories*, which are remote servers that
  8. contain their own database of packages, and may also contain the packages
  9. themselves. An arbitrary number of package repositories may be added to the
  10. local database. When ``dds`` updates its package information, it will download
  11. the package database from each registered remote and import the listings into
  12. its own local database, making them available for download.
  13. Viewing Available Packages
  14. **************************
  15. The default catalog database is stored in a user-local location, and the
  16. available packages can be listed with ``dds pkg search``::
  17. $ dds pkg search
  18. Name: abseil
  19. Versions: 2018.6.0, 2019.8.8, 2020.2.25
  20. From: repo-1.dds.pizza
  21. Name: asio
  22. Versions: 1.12.0, 1.12.1, 1.12.2, 1.13.0, 1.14.0, 1.14.1, 1.16.0, 1.16.1
  23. From: repo-1.dds.pizza
  24. Name: boost.leaf
  25. Versions: 0.1.0, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.3.0
  26. From: repo-1.dds.pizza
  27. Name: boost.mp11
  28. Versions: 1.70.0, 1.71.0, 1.72.0, 1.73.0
  29. From: repo-1.dds.pizza
  30. Optionally, one can search with a glob/fnmatch-style pattern::
  31. $ dds pkg search 'neo-*'
  32. Name: neo-buffer
  33. Versions: 0.2.1, 0.3.0, 0.4.0, 0.4.1, 0.4.2
  34. From: repo-1.dds.pizza
  35. Name: neo-compress
  36. Versions: 0.1.0, 0.1.1, 0.2.0
  37. From: repo-1.dds.pizza
  38. Name: neo-concepts
  39. Versions: 0.2.2, 0.3.0, 0.3.1, 0.3.2, 0.4.0
  40. From: repo-1.dds.pizza
  41. Remote Repositories
  42. *******************
  43. A remote package repository consists of an HTTP(S) server serving the following:
  44. 1. An accessible directory containing source distributions of various packages,
  45. and
  46. 2. An accessible database file that contains a listing of packages and some
  47. repository metadata.
  48. The exact details of the directory layout and database are not covered here, and
  49. are not necessary to make use of a repository.
  50. When ``dds`` uses a repository, it pulls down the database file and imports its
  51. contents into its own local database, associating the imported package listings
  52. with the remote repository which provides them. Pulling the entire database at
  53. once allows ``dds`` to perform much faster dependency resolution and reduces
  54. the round-trips associated with using a dynamic package repository.
  55. Adding a Repository
  56. ===================
  57. Adding a remote repository to the local database is a simple single command::
  58. $ dds pkg repo add "https://repo-1.dds.pizza"
  59. [info ] Pulling repository contents for repo-1.dds.pizza [https://repo-1.dds.pizza/]
  60. This will tell ``dds`` to add ``https://repo-1.dds.pizza`` as a remote
  61. repository and immediately pull its package listings for later lookup. This
  62. initial update can be suppressed with the ``--no-update`` flag.
  63. .. note::
  64. After the initial ``pkg repo add``, the repository is *not* identified by its
  65. URL, but by its *name*, which is provided by the repository itself. The name
  66. is printed the first time it is added, and can be seen using ``pkg repo ls``.
  67. Listing Repositories
  68. ====================
  69. A list of package repositories can be seen with the ``pkg repo ls`` subcommand::
  70. $ dds pkg repo ls
  71. Removing Repositories
  72. =====================
  73. A repository can be removed by the ``pkg repo remove`` subcommand::
  74. $ dds pkg repo remove <name>
  75. Where ``<name>`` is given as the *name* (not URL!) of the repository.
  76. **Note** that removing a repository will make all of its corresponding remote
  77. packages unavailable, while packages that have been pulled into the local cache
  78. will remain available even after removing a repository.
  79. Updating Repository Data
  80. ========================
  81. Repository data and package listings can be updated with the ``pkg repo update``
  82. subcommand::
  83. $ dds pkg repo update
  84. This will pull down the databases of all registered remote repositories. If
  85. ``dds`` can detect that a repository's database is unchanged since a prior
  86. update, that update will be skipped.
  87. The Default Repository
  88. **********************
  89. When ``dds`` first initializes its local package database, it will add a single
  90. remote repository: ``https://repo-1.dds.pizza/``, which has the name
  91. ``repo-1.dds.pizza``. At the time of writing, this is the only official ``dds``
  92. repository, and is populated sparsely with hand-curated and prepared packages.
  93. In the future, the catalog of packages will grow and be partially automated.
  94. There is nothing intrinsically special about this repository other than it being
  95. the default when ``dds`` first creates its package database. It can be removed
  96. as any other, should one want tighter control over package availability.
  97. Managing a Repository
  98. *********************
  99. A ``dds`` repository is simply a directory of static files, so any HTTP server
  100. that can serve from a filesystem can be used as a repository. ``dds`` also
  101. ships with a subcommand, ``repoman``, that can be used to manage a repository
  102. directory.
  103. Initializing a Repository
  104. =========================
  105. Before anything can be done, a directory should be converted to a repository by
  106. using ``repoman init``::
  107. $ dds repoman init ./my-repo-dir --name=my-experimental-repo
  108. This will add the basic metadata into ``./my-repo-dir`` such that ``dds`` will
  109. be able to pull package data from it.
  110. The ``--name`` argument should be used to give the repository a unique name. The
  111. name should be globally unique to avoid collisions: When ``dds`` pulls a
  112. repository that declares a given name, it will *replace* the package listings
  113. associated with any repository of that name. As such, generic names like
  114. ``main`` or ``packages`` shouldn't be used in production.
  115. Listing Contents
  116. ================
  117. The packages in a repository can be listed using ``dds repoman ls <repo-dir>``.
  118. This will simply print each package identifier that is present in the
  119. repository.
  120. Importing Source Distributions
  121. ==============================
  122. If you have a source distribution archive, it can be imported with the
  123. appropriately name ``dds repoman import`` command::
  124. $ dds repoman import ./my-repo some-pkg@1.2.3.tar.gz
  125. Multiple archive paths may be provided at once to import them all at once.
  126. Adding a Package by URL
  127. =======================
  128. A repository can also list packages that it does not host itself. Such a package
  129. listing can be added "by URL," where the URL tells ``dds`` how to pull the
  130. source distribution of the package. Beyond basic HTTP(S) URLs, ``dds`` can also
  131. clone packages via ``git``::
  132. $ dds repoman add ./my-repo git+https://github.com/vector-of-bool/neo-fun.git#0.5.2
  133. The above URL tells ``dds`` that it can use ``git clone`` against
  134. ``https://github.com/vector-of-bool/neo-fun.git`` and ask for tag ``0.5.2`` to
  135. get a source distribution directory that can be imported. Note the fragment on
  136. ``git`` URLs! The fragment is required to specify the branch or tag to clone.
  137. If the package is available on GitHub, ``dds`` has a shorthand URL for that::
  138. $ dds repoman add ./my-repo github:vector-of-bool/neo-fun/0.6.0
  139. The ``github:`` URL scheme tells ``dds`` to clone from GitHub. A ``github:`` URL
  140. must have exactly three path elements to determine *what* to download:
  141. ``github:{owner}/{repository}/{branch-or-tag}``.
  142. .. note::
  143. The ``github:`` URL lacks an *authority* element, and as such *does not* use
  144. the double-slash.
  145. .. note::
  146. ``repoman add`` will immediately attempt to pull a source distribution from
  147. the given URL so that it may import the package's metadata into its listing
  148. database. You cannot add a URL that is not already accessible.
  149. Removing Packages
  150. =================
  151. A package can be removed from a repository with
  152. ``dds repoman remove <repo-dir> <pkg-id>``, where ``<pkg-id>`` is the
  153. ``<name>@<version>`` of the package to remove.