OSProcess packages

In the SqS repository, OSProcess has three different Test "packages":
* OSProcess-Tests included in the OSProcess package
* Tests-OSProcess
* OSProcess-Tests, separately-packaged

Presumably, the last one - and the other packages split out of the OSProcess package - were created for Metacello.

My questions are:
* what is the relationship between these Test packages? Can we remove any to make it less confusing?
* Are the OSProcess and OSProcess-* packages in sync i.e. all have the latest updates?

I want to update the Metacello configuration and don't know how to proceed. B.t.w. I've been loading OSP by using Gofer to load the big OSP package and didn't understand the point of a Metacello config for this type of project - i.e. David has said "just load the latest versions". However, after talking it over with Dale on the Metacello list, I think for deployment it's better to reference a specific version so that everything is exactly reproducible. Metacello also abstracts away the fact that currently the project (may be) only one package, so everything still works if/when that changes. It'd also be nice to unload the tests for deployment, but I guess that's not so urgent.

On Thu, Jun 07, 2012 at 11:02:51AM -0700, Sean P. DeNigris wrote:
> In the SqS repository, OSProcess has three different Test "packages":
> * OSProcess-Tests included in the OSProcess package
> * Tests-OSProcess
> * OSProcess-Tests, separately-packaged
>
> Presumably, the last one - and the other packages split out of the OSProcess
> package - were created for Metacello.

The individual OSProcess-* packages are maintained in order to permit
them to be loaded separately. For example, someone might want a Unix-only
distribution, or a distribution without tests. This should work well
with Metacello.

>
> My questions are:
> * what is the relationship between these Test packages? Can we remove any to
> make it less confusing?

The Tests-OSProcess package is from some period of time when I had the tests
packaged in that way. They are of no current interest but are part of the
archive.

> * Are the OSProcess and OSProcess-* packages in sync i.e. all have the
> latest updates?

Yes.

>
> I want to update the Metacello configuration and don't know how to proceed.

Assuming that you want to load the entire package, you should have the Metacello
config point to the OSProcess package.

> B.t.w. I've been loading OSP by using Gofer to load the big OSP package and
> didn't understand the point of a Metacello config for this type of project -
> i.e. David has said "just load the latest versions". However, after talking
> it over with Dale on the Metacello list, I think for deployment it's better
> to reference a specific version so that everything is exactly reproducible.
> Metacello also abstracts away the fact that currently the project (may be)
> only one package, so everything still works if/when that changes. It'd also
> be nice to unload the tests for deployment, but I guess that's not so
> urgent.

If you want to have a distribution without the tests, you can use a Metacello
config that points to all of OSProcess-* except for OSProcess-tests.

Dave

That sounds like a lot of work to maintain. When you want to save new functionality, how do you save it as individual packages and then as one big package?

On Thu, Jun 07, 2012 at 03:53:26PM -0700, Sean P. DeNigris wrote:
> That sounds like a lot of work to maintain. When you want to save new
> functionality, how do you save it as individual packages and then as one big
> package?
>

Yes, that's right. It's a real pain. In hindsight, I wish I had never split
the main OSProcess package into smaller pieces. But now that it's done, I
feel like I should keep it all up to date.

On the other hand, I did the same thing with CommandShell, and I think
it was the right choice in that case. I first split CommandShell out of
OSProcess (quite a long time ago), and then I split CommandShell into
CommmandShell-* packages that I maintain exactly as you describe above.
This should make it possible for most people to load the full CommandShell
package, but someone who only wants to use a PipableOSProcess can load a
subset.  I'm not sure if anyone is actually making use of this, but it does
seem like the right thing to do, even if it is a bit more work to maintain
the packages.

Conclusion: Modularity is like beer. Beer is good, but more beer is not
always better.

Dave