jimporter / mopack Goto Github PK
View Code? Open in Web Editor NEWMultiple origin package management
Home Page: https://jimporter.github.io/mopack
License: BSD 3-Clause "New" or "Revised" License
Multiple origin package management
Home Page: https://jimporter.github.io/mopack
License: BSD 3-Clause "New" or "Revised" License
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.
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...
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.
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
.
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.
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.
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.
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)
Right now, we only support a limited set of base directories. We could add the ability for build steps to create arbitrary base dirs so that it's easy to chain together lots of build steps. (I'm not sure this will come up often in practice though. Isn't a single build dir plenty?)
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.
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).
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.
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.
There are some warts/missing bits with submodules, especially on the doc side. We should also add submodule_map
to export
in mkdocs.yml
.
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.
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...)
This is pretty self-explanatory; just detect command lines of the form cd whatever
and do it ourselves via Python function calls.
Apparently, vcpkg supports emitting pkg-config files, so it should be relatively straightforward to support it as one of the mopack source types.
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".
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.