Difference between revisions of "User:Nathan M. Swan/DPM Proposal"

From D Wiki
Jump to: navigation, search
Line 4: Line 4:
  
 
== Scenarios ==
 
== Scenarios ==
I want it to cover the largest range of use cases as possible, so it should be extendable, but the basic use case should be easy. These are the two main UXs:
+
I want it to cover the largest range of use cases as possible, so it should be extendable, but the basic use case should be easy. These are the three main UXs:
  
 
* Install a package
 
* Install a package
 +
* Update a package
 
* Create a package
 
* Create a package
  
Line 14: Line 15:
 
You enter the command:
 
You enter the command:
  
     $ dpm install <repository> [<options>]
+
     $ dpm install <repository> [<version>]
  
 
The repository can be a "genuine" or "pseudo" package. A genuine package has been created with <code>'''dpm'''</code>, which means that it simply follows the instructions of the dpm configuration file.
 
The repository can be a "genuine" or "pseudo" package. A genuine package has been created with <code>'''dpm'''</code>, which means that it simply follows the instructions of the dpm configuration file.
  
Pseudo-packages are D code repositories that have yet to use dpm. This means that guesswork in how to run it will be involved, which includes:
+
Pseudo-packages are D code repositories that have yet to use dpm. Because of this, it will open a shell in the top directory of the installed repository, telling the user they will have to install it manually, encouraging them to checkout the READMEs and INSTALLs.
* Running a <code>build.d</code>, if it exists.
+
 
* Running a makefile
+
Genuine packages have a file <code>dpmconfig.d</code> at the top directory, which contains the code run to install the package. Technically, it can do what it wants, though it most likely will <code>import dpm;</code>, a separate D file compiled alongside it. That file will contain a series of useful functions for making it easy to program the config file, including ways to call common build methods like <code>make</code> or <code>rdmd</code>.
 +
 
 +
=== Updating packages ===
 +
Simply uninstalls/reinstalls the package.
 +
 
 +
=== Creating packages ===
 +
Migrating to <code>dpm</code> should be easy. Therefore, users with existing build options shouldn't have to redo it, just have <code>dpmconfig.d</code> call existing build code.
 +
 
 +
There will be a <code>dpm</code> command called <code>create</code>, which has a <code>--template</code> option which automatically generates these templates:
 +
 
 +
    make -> make
 +
    make-install -> make install
 +
    make-make-install -> make; make install
 +
    rdmd-build -> rdmd build.d
 +
    empty -> does nothing
 +
 
 +
There will be an <code>--exec</code> option which directly inserts code into the config file.
 +
 
 +
Example bare-bones config file:
 +
<syntaxhighlight lang="D">
 +
import dpm;
 +
void dpm_main() {
 +
    make();
 +
}
 +
</syntaxhighlight>
 +
 
 +
=== Repository Resolution ===
 +
The repository can be either a URL to an exact git repository, or a simple package name.
 +
 
 +
If it's an exact git repository, the version is assumed to be a tag, with a <code>--branch</code> alternative.
 +
 
 +
A simple package name means it must be downloaded from a central package repository (CPR). It goes through all installed CPRs and makes this HTTP request:
 +
 
 +
    <cpr, e.g. http://cpr.example.com/cpr_api/>?name=<repository_name>[version=<version>]
 +
 
 +
The CPR gives the URL of a git repository and <code>--branch</code>/tag as a plain text response (code 200), or it gives a custom error message (code 404). It then treats that as an ordinary git repository.
 +
 
 +
When a standard CPR is created, it will be builtin as the default CPR. Users can <code>dpm add-cpr <url></code> or <cod>dpm rm-cpr <url></code>, as they wish, modifying a config file somewhere.

Revision as of 02:22, 11 December 2012

WORK IN PROGRESS, IGNORE FOR NOW

This is a proposal for dpm, a D package manager. The eventual goal is to get this accepted into the standard distribution of D, so I don't want to start working on this until I get feedback from the community.

Scenarios

I want it to cover the largest range of use cases as possible, so it should be extendable, but the basic use case should be easy. These are the three main UXs:

  • Install a package
  • Update a package
  • Create a package

Where will these "packages" be hosted? Sometime in the future, we would ideally have a central repository that hosts them like RubyGems, but for now we will rely on git repositories from anywhere (like Github).

Installing packages

You enter the command:

   $ dpm install <repository> [<version>]

The repository can be a "genuine" or "pseudo" package. A genuine package has been created with dpm, which means that it simply follows the instructions of the dpm configuration file.

Pseudo-packages are D code repositories that have yet to use dpm. Because of this, it will open a shell in the top directory of the installed repository, telling the user they will have to install it manually, encouraging them to checkout the READMEs and INSTALLs.

Genuine packages have a file dpmconfig.d at the top directory, which contains the code run to install the package. Technically, it can do what it wants, though it most likely will import dpm;, a separate D file compiled alongside it. That file will contain a series of useful functions for making it easy to program the config file, including ways to call common build methods like make or rdmd.

Updating packages

Simply uninstalls/reinstalls the package.

Creating packages

Migrating to dpm should be easy. Therefore, users with existing build options shouldn't have to redo it, just have dpmconfig.d call existing build code.

There will be a dpm command called create, which has a --template option which automatically generates these templates:

   make -> make
   make-install -> make install
   make-make-install -> make; make install
   rdmd-build -> rdmd build.d
   empty -> does nothing

There will be an --exec option which directly inserts code into the config file.

Example bare-bones config file:

import dpm;
void dpm_main() {
    make();
}

Repository Resolution

The repository can be either a URL to an exact git repository, or a simple package name.

If it's an exact git repository, the version is assumed to be a tag, with a --branch alternative.

A simple package name means it must be downloaded from a central package repository (CPR). It goes through all installed CPRs and makes this HTTP request:

   <cpr, e.g. http://cpr.example.com/cpr_api/>?name=<repository_name>[version=<version>]

The CPR gives the URL of a git repository and --branch/tag as a plain text response (code 200), or it gives a custom error message (code 404). It then treats that as an ordinary git repository.

When a standard CPR is created, it will be builtin as the default CPR. Users can dpm add-cpr <url> or <cod>dpm rm-cpr <url>, as they wish, modifying a config file somewhere.