<html><head></head><body>
<p>Hi Chris,<br/>
</p>
<div class="moz-cite-prefix">On 3/9/20 7:37 PM, Chris Muller wrote:<br/>
</div>
<blockquote type="cite" cite="mid:CANzdToF4Pd24RqCrDJh5wx0bkt7c37g8VXNUh3XNib+sKvhDfw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 9, 2020 at
6:41 PM Robert via Squeak-dev <<a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank" moz-do-not-send="true">squeak-dev@lists.squeakfoundation.org</a>>
wrote:<br/>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">I see, alright,
that's fair dinkum. I also feel strongly that a
minimum <br/>
of tests be carried within the primary package for
some code. If you <br/>
look at the Crypto packages, you'll see Hashing tests
in hashing, Random <br/>
tests in Random, Cipher tests in Cipher. This way it
is easy to run <br/>
them, off a CI server or what have you. The tests come
with the code, is <br/>
a principle I try to follow.<br/>
</blockquote>
<div><br/>
</div>
<div>Just my .02: I don't like the approach of putting
tests with the code. I'm absolutely in favor of
having as many tests as make sense, just please put
them in a separate package. While your approach seems
reasonable for people who are working interactively on
code and want to make sure things stay working as they
are making changes, it doesn't make sense when what
you are going for is a minimal or server image where
the existing code is just being used, not actively
developed.</div>
</div>
</div>
</blockquote>
<div><br/>
</div>
<div>+1 Everyone has different configuration needs. As you
know from your recent investigations on dependencies, it
doesn't mean the ability to load (Core+Tests) has to require
two clicks, it can still be just one. Including tests is
not useful for the use-case of "verifying you're running the
correct software" either, only an externally applied
signature scheme can do that, since you have to verify the
tests packages, too.</div>
</div>
</div>
</blockquote>
<p>1) I totally see the benefits of separate tests, but how to
manage them best? <br/>
</p>
<p>The shortcoming is in conditional dependencies. I stil lhave a
weak understanding of .mcm files, for Monticello Configurations.
Is it possible to specify a conditional dependency, so when #tests
are loaded, all the #core components have a #tests dependency,
that is installed when requested? I do not know. It needs to be
so. <br/>
</p>
<p>I'll point to a page in Java, which has definitely solved this
class of needs. They use a small language, like Maven, or a full
blown language, like Gradle, in Groovy. Maven relies on a .POM
file, a json encoded specifications. Maven works in terms of
archives. They build artifacts and their dependencies are
artifacts. A dependent artifact specifies the repository, the
archive name/id in that repository and you can specify conditions,
like a load specification for #tests. When you run the maven POM
you specify #build or #tests or whatever target tag you use
(#archive). I am unsure if we have this capability, we should.
Can we extend Monticello forwards to language oriented package
& dependency management, yet still be backwards compatible?
Can we attach a "POM" file to the Monticello artifact? How does a
Monticello Configuration work?<br/>
</p>
<p>2) How can loading #core + #test be one-click? I would like to
know.<br/>
</p>
<p>3) I think validating vm components is a different conversation,
entirely.</p>
<p><br/>
</p>
<p>K, r</p>
<p><br/>
</p>
<blockquote type="cite" cite="mid:CANzdToF4Pd24RqCrDJh5wx0bkt7c37g8VXNUh3XNib+sKvhDfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> - Chris</div>
</div>
</div>
</blockquote>
</body></html>