jimporter / mopack Goto Github PK

Error reporting for expressions (stuff like ${{ foo }}) could use improvement. Only stuff inside if directives will adjust the caret to point to the actual problem, and even then, that behavior is probably wrong for multiline YAML strings (since YAML strips out newlines, whitespace, etc). We should fix this.

We should also improve the actual error messages where possible; they can be pretty unhelpful. I'm not really sure how to do this with pyparsing yet...

Currently, mopack usage returns different kinds of usages depending on the package config. This is annoying for consumers of mopack, since they have to handle all possible cases, or some configs just won't work. However, it's not clear to me yet if pkg-config is sufficient for all use cases. Maybe there's something better? Maybe flexibility is good? (Ok, probably not on that last one...)

To help make more reproducible builds, we could keep track of the exact results of package lookups. This way, even if something about the environment changes, we'll still have consistent results (although sometimes this might just mean a build failure).

(See also jimporter/bfg9000#10)

There are some warts/missing bits with submodules, especially on the doc side. We should also add submodule_map to export in mkdocs.yml.

For v0.1, we should have proper documentation. We really just need enough that people could write a reasonably-complex mopack.yml and also hook it into a build system if they're not using bfg.

• Introduction
• User Guide
  • Resolving Packages with mopack.yml
  • Writing mopack.yml
• Reference
  • File Structure
    • Exports
    • Options
    • Packages
  • Packages
  • Builders
  • Usage
    • Usage Results
  • Expressions
    • Introducing expressions
    • Literals
    • Operators
    • Variables
  • Command-line Reference
  • Environment Variables

Building is fundamentally a step-by-step process, and there might be extra pre- or post-steps that you need in addition to some high-level step(s) like cmake or bfg9000. We should support this, and make the default cmake/bfg9000 build steps just implicitly generate 2 steps (configure and then actually build).

Once things stabilize, we should add versioning to each source/builder/etc so that when there's an API break for that thing, we can easily detect it and upgrade the mopack.json data.

Parsing expressions with the generated parser from pyparsing is slow for any non-trivial cases (shocking, I know). It would probably be a good idea to move the parser to C, maybe with flex/bison.

This is pretty self-explanatory; just detect command lines of the form cd whatever and do it ourselves via Python function calls.

Currently, it's possible to send specific environment variables off to a remote server by using variable interpolation. This could conceivably be a security issue. However, since we're also running arbitrary scripts to build, the cat's already out of the bag.

Potentially, we might want to restrict variable interpolation in URLs if we later added the option to fetch deps without building them, and then build them separately. Then a user could enable their internet connection for the fetch and disable it during building to be safer.

Currently, mopack just resolves every package in the mopack.yml file(s). We should support the ability to specify optional dependencies that only apply under certain configurations.

Currently, the {submodule} placeholder is just a string placeholder for use with str.format. Since we have real variable interpolation now, we should use that. However, this will take some thought, since we're already using variable placeholders for Path objects, and the API isn't (yet) built to allow multiple kinds of placeholder.

The new package defaults system (using YAML files) seems like a good place to move the platform-specific library name mapping. However, since package defaults operate on the level of, well, packages, this would require some substantial changes.

One possibility would be for all the special library name mappings to be represented as their own packages, but then we'd need a way to represent a dependency on those packages, at least for path usage. This is relatively straightforward if the base package also uses path usage, but is complicated by the fact that those packages might use pkg-config usage. This could be remedied by having the path usage generate a pkg-config file (effectively mandating pkg-config for consumers of mopack): see #12.

system usage is really just "try pkg-config usage, and fall back to path usage otherwise". Rather than having a special-purpose usage for this, we could provide a list of usages and then use the first valid one, sort of like how packages can have multiple definitions.

Basically, go through all dependencies recursively and collect their license information, then display it to the user and/or check against a set of rules for what licenses are ok.

For some dependent packages (e.g. mettle), it would be nice to be able to export their executable(s). That way, you could build it from source via mopack and use the executable in your parent package's build process.

It's a multiple origin package manager, and this also makes it less confusing since source can mean "where we got this dependency from" or "the dependency's source code".

Apparently, vcpkg supports emitting pkg-config files, so it should be relatively straightforward to support it as one of the mopack source types.

To help migrate from bfg v0.6, we need a compatibility layer that allows bfg scripts to specify expected headers/libs. This can then get forwarded to mopack via the usage subcommand, as something like --x-headers and --x-libraries.