pkg

README

pkg

Package for reading and manipulating 'dvln' tool packages (pkg)

Usage

Any usage overview...

Basic usage:

Public methods, example uses, etc Put calls throughout your code based on desired "levels" of messaging. Simply run calls to the output functions:

• pkg.Method1(...)
• pkg.Method2(...)

Example usage:

    import (
        "github.com/dvln/pkg"
    )

    ...
    // Read details about a pkg
    pkg.Read(...)

Blah blah blah

Optionally configure VCS 'pkg'

...

Configuration one

Enable blah blah blah:

    import (
        "github.com/dvln/pkg"
    )

    ...
    // set up a temp file for our tools output (we can print the
    // file name out at the end of our tools run so users know it),
    // call this early in your app if you want to log everything
    ...

Blah blah

Configuration two

Enable blah blah blah:

    import (
        "github.com/dvln/pkg"
    )

    ...
    // set up a temp file for our tools output (we can print the
    // file name out at the end of our tools run so users know it),
    // call this early in your app if you want to log everything
    ...

Blah blah

Configuration three

Enable blah blah blah:

    import (
        "github.com/dvln/pkg"
    )

    ...
    // set up a temp file for our tools output (we can print the
    // file name out at the end of our tools run so users know it),
    // call this early in your app if you want to log everything
    ...

Blah blah

Environment settings

Blah blah...

• PKG_PKG_BLAH BLAH env set to "1" causes ... for blah blah and other things blah blah

Current status

This is a very early release... needs more work, blah blah

Documentation

Overview

Package pkg contains structures and methods related to pkg definitions from a 'dvln' codebase. These packages might be of any of these types: - a "leaf" pkg: identifying a simple "single" repo (git, hg, etc) - a "dvln" pkg: same as leaf but also contains a "sub" dvln (pkg manifest) - a "codebase" pkg: this pkg contains a codebase defn inside it (see codebase pkg)

A package may be arbitrarily defined (eg: within a codebase definition file) or may be instantiated at a given version inside a users workspace (or by querying some version of a pkg on the server). This is generic info this run of the tool has about the pkg (in it's current "use", eg: if querying a diff from the server with no workspace we may indicate what the workspace path would be if it were instantiated but that path won't exist whereas if we have a workspace we could find the package there in the workspace.

Index

• type Class
• type Defn
• type Rev
• type RevType
• type Revision
• type VCSFmt

Types

type Class

type Class string

Class defines the "class" of 'dvln' pkg: unknown, single, group or codebase

const (
	UnknownClass Class = ""
	Single       Class = "single"
	Group        Class = "group"
	Codebase     Class = "codebase"
)

dvln 'pkg' classes, ie "single pkg", "group pkg", "codebase pkg"

type Defn

type Defn struct {
	ID       int                 `json:"id"`
	Name     string              `json:"name"`
	Aliases  map[string]string   `json:"aliases,omitempty"`
	Desc     string              `json:"desc,omitempty"`
	Contacts map[string][]string `json:"contacts,omitempty"`
	Ws       string              `json:"ws,omitempty"`
	Class    Class               `json:"class,omitempty"`
	Deps     string              `json:"deps,omitempty"`
	VCS      []VCSFmt            `json:"vcs,omitempty"`
	Arch     []string            `json:"arch,omitempty"`
	OS       []string            `json:"os,omitempty"`
	Stage    []string            `json:"stage,omitempty"`
	Attrs    map[string]string   `json:"attrs,omitempty"`
	License  string              `json:"license,omitempty"`
	Issues   url.URL             `json:"issues,omitempty"`
	Access   map[string]string   `json:"access,omitempty"`
	Status   string              `json:"status,omitempty"`
}

Defn identifies the data needed to "define" a dvln "package"... *not* including any specific version information. This is all about basic package details... VCS info for the package, where it will exist in the workspace (ie: sandbox or work tree), what a pkg might have been called in the past or aliases that it might still need to be referenced by, etc

type Rev

type Rev struct {
	ID      int            `json:"id"`
	Name    string         `json:"name"`
	Rev     string         `json:"rev"`
	RevType string         `json:"rev_type"`
	Deps    map[int]string `json:"deps"`
	VCS     vcs.Reader
}

Rev indicates the basic data needed for a given VCS pkg revision. The name is useful for messaging and such whereas the ID is used for trivial lookup of the package meta-data in the codebase/pkg definition.

type RevType

type RevType string

RevType is an indicator if a revision is static or dynamic (or unknown)

const (
	UnknownRevType RevType = ""
	Dynamic        RevType = "dynamic"
	Static         RevType = "static"
)

dvln 'pkg' revision status, is it dynamic or static (or unknown)?

type Revision

type Revision interface {
	Exists(pkgRevSel string) (string, error)
	Get(pkgRevSel string) error
	Pull(pkgRevSel string) error
}

Revision is a package revision (ie: VCS version), anything one might need to do with a revision will be part of the interface (and hence can be mock'd to ease testing and such)

type VCSFmt

type VCSFmt struct {
	Type    vcs.Type                     `json:"type,omitempty"`
	Fmts    []string                     `json:"fmts,omitempty"`
	Repo    map[string]string            `json:"repo,omitempty"`
	Remotes map[string]map[string]string `json:"remotes,omitempty"`
}

VCSFmt contains information about a given format like the 'git' format for a component (aliases might be ["src,source"] so that if a user asks for the generic "src" format it'll grab the git format, whereas if they ask for the "bin" format maybe that's an alias for the "rpm" format of the pkg). The Repo contains VCS repo pointers for read, write, review, etc URL's or central pointers. The remotes allows one to set up additional remotes besides the place one pulled the code from (eg: from the canonical central vendor repo instead of my local fork, I might want a remote for that auto-added in my wkspc clone so I can merge from it easily)