Struct axoproject::PackageInfo

pub struct PackageInfo {

    pub manifest_path: Utf8PathBuf,
    pub package_root: Utf8PathBuf,
    pub name: String,
    pub version: Option<Version>,
    pub description: Option<String>,
    pub authors: Vec<String>,
    pub license: Option<String>,
    pub publish: bool,
    pub keywords: Option<Vec<String>>,
    pub repository_url: Option<String>,
    pub homepage_url: Option<String>,
    pub documentation_url: Option<String>,
    pub readme_file: Option<Utf8PathBuf>,
    pub license_files: Vec<Utf8PathBuf>,
    pub changelog_file: Option<Utf8PathBuf>,
    pub binaries: Vec<String>,
    pub cstaticlibs: Vec<String>,
    pub cdylibs: Vec<String>,
    pub cargo_metadata_table: Option<Value>,
    pub cargo_package_id: Option<PackageId>,
    pub build_command: Option<Vec<String>>,
}

Computed info about a package

This notably includes finding readmes and licenses even if the user didn’t specify their location – something Cargo does but Guppy (and cargo-metadata) don’t.

Fields

manifest_path: Utf8PathBuf

Path to the manifest for this package

package_root: Utf8PathBuf

Path to the root dir for this package

name: String

Name of the package

This can actually be missing for JS packages, but in that case it’s basically the same thing as a “virtual manifest” in Cargo. PackageInfo is only for concrete packages so we don’t need to allow for that.

version: Option<Version>

Version of the package

Both cargo and npm use SemVer but they disagree slightly on what that means:

• cargo: https://crates.io/crates/semver
• npm: https://crates.io/crates/node-semver

Cargo requires this field at all times, npm only requires it to publish. Probably we could get away with making it non-optional but allowing this theoretically lets npm users “kick the tires” even when they’re not ready to publish.

description: Option<String>

A brief description of the package

authors: Vec<String>

Authors of the package (may be empty)

license: Option<String>

The license the package is provided under

publish: bool

False if they set publish=false, true otherwise

Currently always true for npm packages.

keywords: Option<Vec<String>>

Package keywords AND/OR categories.

Specifically, Cargo has both the notion of a “package keyword” (free-form text) and a “package category” (one of circa 70 predefined categories accepted by crates.io). We don’t really care about validating these, though, and just squash them together with the keywords.

repository_url: Option<String>

URL to the repository for this package

This URL can be used by various CI/Installer helpers. In the future we might also use it for auto-detecting “hey you’re using github, here’s the recommended github setup”.

i.e. cargo dist init --installer=shell uses this as the base URL for fetching from a Github Release™️.

homepage_url: Option<String>

URL to the homepage for this package.

Currently this isn’t terribly important or useful?

documentation_url: Option<String>

URL to the documentation for this package.

This will default to docs.rs if not specified, which is the default crates.io behaviour.

Currently this isn’t terribly important or useful?

readme_file: Option<Utf8PathBuf>

Path to the README file for this package.

If the user specifies where this is, we’ll respect it. Otherwise we’ll try to find this in the workspace using AutoIncludes.

license_files: Vec<Utf8PathBuf>

Paths to the LICENSE files for this package.

By default these should be copied into a zip containing this package’s binary.

If the user specifies where this is, we’ll respect it. Otherwise we’ll try to find this in the workspace using AutoIncludes.

Cargo only lets you specify one such path, but that’s because its license-path key primarily exists as an escape hatch for someone’s whacky-wild custom license. Ultimately Cargo’s license-path is inadequate for Normal Licenses because it can’t handle the standard pattern of dual licensing MIT/Apache and having two license files. AutoIncludes properly handles dual licensing.

changelog_file: Option<Utf8PathBuf>

Paths to the CHANGELOG or RELEASES file for this package

By default this should be copied into a zip containing this package’s binary.

We will try to parse this

binaries: Vec<String>

Names of binaries this package defines

For Cargo this is currently properly computed in all its complexity. For JS I think this is computed in its full complexity but Tests Needed and also there’s so many ways to define things who can ever be sure.

cstaticlibs: Vec<String>

Names of C-style staticlibs (.a) this library defines.

For Cargo this is currently properly computed in all its complexity. For JS we don’t compute this at all.

cdylibs: Vec<String>

Names of C-style dylibs (.dll, .so, …) this package defines

For Cargo this is currently properly computed in all its complexity. For JS we don’t compute this at all.

cargo_metadata_table: Option<Value>

Raw cargo [package.metadata] table

cargo_package_id: Option<PackageId>

A unique id used by Cargo to refer to the package

build_command: Option<Vec<String>>

Command to run to build this package

Implementations

impl PackageInfo

pub fn changelog_for_version( &self, version: &Version, ) -> Result<Option<ChangelogInfo>>

Get the changelog for a given version from a package’s changelog

impl PackageInfo

pub fn github_repo(&self) -> Result<Option<GithubRepo>>

Returns a struct which contains the repository’s owner and name.

pub fn web_url(&self) -> Result<Option<String>>

Returns a web version of the repository URL, converted from SSH if necessary, with .git suffix trimmed.

Trait Implementations

impl Debug for PackageInfo

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.