V: Specify external package structure

[Undumendil]

It should be the first step of implementing a package manager later.

[Undumendil]

What metainformation a package may contain?

1. Name
2. Version
3. Supported architectures (or 'all')
   ?[One should be able to try using it anyway.]
4. Supported OS (or 'all')
   ?[One should be able to try using it anyway.]
5. Hardware/firmware/software requirements + feature description (e.g. 'NVIDIA GPU: GPU-accelerated video processing', 'RTL-SDR: FM radio input', 'gnuplot: Draw plots')
   ?[In case of failed check or impossibility to check compiler should show a warning, not cause a failed build.] ?[Successful checks may set flags to be checked with $if feature { ... }.] ?[One should always be able to pass specific checks.]
6. A list of dependencies
7. ..?

[Undumendil]

Packages will need a configuration file. I suggest using a V.conf JSON file (since there is a JSON parser already used) in package root with the following structure:

{
    "name": "package-name",
    "v": "1.0",
    "os": "all|win|linux|mac|android|...",
    "arch": "all|...",
    "req": {
        "some-flag": {
            "type": "executable|warning|...",
            "what": "check-key",
            "desc": "Feature description"
        }
    },
    "dep": {
        "lib1": "gh:example/lib1",
        "lib2_1": "gh:example/lib2:1.2",
        "lib2_2": "gh:example/lib2:>=2.2,<2.3"
    }
}

Package gh:example/lib2 can be imported and used separately as lib2_1 and lib2_2. In case of github source (gh:) tags may be used to search for specific versions.
The same structure may be used to specify dependencies of local projects. These files should be created and edited by the package manager. I suggest implementing the following commands:

• v init [[-n|--name] NAME] [-v|--version VERSION] [-o|--os OS] [-a|--arch ARCH]
  Create V.conf. NAME is named as the current directory if not specified. VERSION is 1.0 if not specified. OS is all if not specified. ARCH is all if not specified.
• v get
  Download missing dependencies into .dep directory and run OS/arch checks.
• v get [-s|--source SOURCE] PACKAGE [[-v|--version] VERSION] [-a|--alias ALIAS] [-f|--force]
  Add dependency, update V.conf, download the package into .dep/ALIAS and (if there is no -f flag) run OS/arch checks. ALIAS is set to PACKAGE if not specified. ALIASes of indirect dependencies may be renamed to avoid conflicts or multiple copies of a single package.
• v remove [-a|--alias] ALIAS
  Remove dependency from .dep, update V.conf, warn if ALIAS is imported in source files.
• v add-feature [-f|--flag FLAG] [-t|--type] TYPE [-w|--what] WHAT [-d|--desc] DESC
  Add feature, update V.conf. FLAG is set to WHAT if not specified.
• v remove-feature [-f|--flag] FLAG
  Remove feature, update V.conf.
• v . [[--force-pass [ALIAS[.SUBALIAS...]:]FEATURE] [--force-fail [ALIAS[.SUBALIAS...]:]FEATURE] ...] [other flags]
  Run v get if necessary, run feature checks, set feature flags, start the build with -lib .dep/ALIAS for every package mentioned in V.conf.

[zac-garby]

Not too keen on using JSON for this. It's harder to read and write for humans, despite being easy for computers. Personally, I'd go with YAML or TOML, or even a bespoke configuration language.

[toddbluhm]

This is a great start to the discussion, but I think perhaps we should take a step back first and ask ourselves what are some of the primary goals of this descriptor file.

I think we should start off with a very simple descriptor file for now, and then we can always expand it later as needs arise and new problems become evident.

Here are some of my thoughts on goals for a descriptor file (note these are not fields, just goals):

• Package Versioning
• Package Dependencies
• Package Name
• Package Location
• Package License

Here are some things that I think should not be initial goals:

• Package entry point (we should stick with the V philosophy of only one way, so the entry point file will always be the same name across all packages)
• Hardware/OS/system specific requirements (this may be required in the future, but at such an early stage I don't think we should over complicate it right now)
• Trying to solve all possible use cases at this time

Thoughts or comments on these goals or any additional input. I think once we nail down some goals we can then focus our efforts on achieving those goals through various fields and options.

[spytheman]

What do you mean by Package Location @toddbluhm ?

[toddbluhm]

Great question! My thinking on Package Location was where is this package source hosted/located. The idea behind this is to make updating/upgrading the package easier.

Like v update package-name then v uses the location info to fetch/retrieve whatever version is requested (defaulting to latest if no version specified). The information could be a git url, package repository name, etc. maybe even multiple locations for fall back? Not really sure how it would be implemented in the definition file yet, but some way of communicating where the package is from/located for updating purposes. This information could also be pulled into a lock file for dependency/transient dependency information when used in another project/package.

[nedpals]

Closed. See the spec at #4926