On Mon, Mar 9, 2020 at 6:41 PM Robert via Squeak-dev < squeak-dev@lists.squeakfoundation.org> wrote:
I see, alright, that's fair dinkum. I also feel strongly that a minimum of tests be carried within the primary package for some code. If you look at the Crypto packages, you'll see Hashing tests in hashing, Random tests in Random, Cipher tests in Cipher. This way it is easy to run them, off a CI server or what have you. The tests come with the code, is a principle I try to follow.
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.
+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.
- Chris
Hi Chris,
On 3/9/20 7:37 PM, Chris Muller wrote:
On Mon, Mar 9, 2020 at 6:41 PM Robert via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
I see, alright, that's fair dinkum. I also feel strongly that a minimum of tests be carried within the primary package for some code. If you look at the Crypto packages, you'll see Hashing tests in hashing, Random tests in Random, Cipher tests in Cipher. This way it is easy to run them, off a CI server or what have you. The tests come with the code, is a principle I try to follow.
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.
+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.
1) I totally see the benefits of separate tests, but how to manage them best?
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.
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?
2) How can loading #core + #test be one-click? I would like to know.
3) I think validating vm components is a different conversation, entirely.
K, r
- Chris
Hi Robert,
- How can loading #core + #test be one-click? I would like to know.
The two links I sent you the other day document it. As a comparable
example, take a look at Installer>>#ffiTests. With this, you can simply execute:
Installer new merge: #ffiTests
and it'll know to grab #ffi first, then #ffiTests.
A second approach can be done with SqueakMap. With a base image, you can load the Magma project, and it'll load the tree of pre-requisites first. Right click on the "1.62 tests" Release, then select "Edit Release" and you'll see the script. This is the incantation which handles the dependencies:
(Smalltalk hasClassNamed: #MaObjectRepository) ifFalse: [ SMSqueakMap default installPackageNamed: 'Magma' version: '1.62 server' ].
So, "1.62 tests" loads "1.62 server", which loads "1.62 client" which loads.... etc.
MC Configurations are yet another way, as is Metacello. I doubt we need any more at the moment.
- Chris
cryptography@lists.squeakfoundation.org
-
Chris Muller -
Robert