On Mon, 2019-11-04 at 14:20 -0500, Matthew Miller wrote:
It would be useful for that contributor to be able to say "I
build
these
packages so I can ship the thing I'm invested in, but... user and
other
contributors, beware".
Now, solving that isn't in the requirements modularity, but it
*is*
something that'd be nice to address, so if modularity happens to,
cool.
The post that Stephen wrote seems to say that solving this is in the
requirements of modularity. Specifically this section:
Defining the public API
Similarly, there are times when an application the packager cares
about depends on another package that is required at runtime, but
sufficiently complex that the packager would not want to maintain it
for general use. (For example, an application that links to a
complicated library but only uses a few functions.)
In this case, we want there to be a standard mechanism for the
packager to be able to indicate that some of the output artifacts are
not supported for use outside this module. If they are needed by
others, they should package it themselves and/or help maintain it in
a shared place.
Requirement: Packagers must be able to encode whether their output
artifacts are intended for use by other projects or if they are
effectively private to the alternative version. Packagers must also
have a way of finding this information out so they understand what
they can and cannot rely on as a dependency.
Is it a requirement? Or did you mean something else?