mini component distribution question

[Eric S. Johansson]

as one would expect when creating a body of software, eventually you
create a series of relatively generic components you find yourself using
over and over again. As a result, I'm finding myself slightly bit by
the same problem I have faced multiple times of the past. Namely, how
do you distribute "small" components that are used in a series of larger
applications.

Yes, I could turn each 300 line file into a Python module complete with
its own source code control and installation framework. Seems like a
bit of overkill however. I also know I could cluster them together into
a larger module but I would end up with something as unwieldy as twisted
or zope. I'm just trying to make a couple of nuts and bolts available,
not a whole railcar full.

Then there's the assembly problem, pulling together all of the disparate
pieces into the application for distribution. Do you pull them together
before you make a tar ball or do you pull them together during
installation ala cpan. there really should be some automated method for
pulling together components when building an application. how many
components is it reasonable to expect an admin to manually download?
Two? Five? 100?

I'd like to know if I'm missing something. Mini modules management and
distribution should be possible without too much headache.

--- eric

 

[Serge Orlov]

as one would expect when creating a body of software, eventually you
create a series of relatively generic components you find yourself using
over and over again. As a result, I'm finding myself slightly bit by
the same problem I have faced multiple times of the past. Namely, how
do you distribute "small" components that are used in a series of larger
applications.

Yes, I could turn each 300 line file into a Python module complete with
its own source code control and installation framework. Seems like a
bit of overkill however. I also know I could cluster them together into
a larger module but I would end up with something as unwieldy as twisted
or zope. I'm just trying to make a couple of nuts and bolts available,
not a whole railcar full.

Then there's the assembly problem, pulling together all of the disparate
pieces into the application for distribution. Do you pull them together
before you make a tar ball or do you pull them together during
installation ala cpan. there really should be some automated method for
pulling together components when building an application. how many
components is it reasonable to expect an admin to manually download?
Two? Five? 100?

How about one? I bundle everything together. Sharing modules at end
user host is more difficult because you have to test many combinations.
Needless to say, end users also have a strange ability to create
untested combinations of modules

I'd like to know if I'm missing something. Mini modules management and
distribution should be possible without too much headache.

I organize projects in workspaces, where workspace consist of several
projects pulled together from different source code repositories. And I
also have small scrips to manage workspaces, for example, I don't use
versioning system directly like "svn update" but run project specific
update.py. If I want to share a mini-module I modify update.py not to
update this module by default. So it works like this: projects X and Y
share module C. Project X improves C and commits new version of C,
which actually can break project Y. But since my update script won't
fetch a new version of C by default, project Y is not affected. When
project Y is ready for update, they run "update.py C", test, fix C and
commit the fixed C. Project X updates C when they are ready to do it.
Work like a charm for me.

 

[Eric S. Johansson]

How about one? I bundle everything together. Sharing modules at end
user host is more difficult because you have to test many combinations.
Needless to say, end users also have a strange ability to create
untested combinations of modules

it's the exact same problem.if you make a change in one file that has
compatibility problems with other uses than that one module blocks all
upgrades on all other modules.

I organize projects in workspaces, where workspace consist of several
projects pulled together from different source code repositories. And I
also have small scrips to manage workspaces, for example, I don't use
versioning system directly like "svn update" but run project specific
update.py. If I want to share a mini-module I modify update.py not to
update this module by default. So it works like this: projects X and Y
share module C. Project X improves C and commits new version of C,
which actually can break project Y. But since my update script won't
fetch a new version of C by default, project Y is not affected. When
project Y is ready for update, they run "update.py C", test, fix C and
commit the fixed C. Project X updates C when they are ready to do it.
Work like a charm for me.

I was thinking of something like that except I was thinking about what
it would mean to have a script that would produce individual modules
using the exact same template for all of the individual module files
within a module cluster. But then I started thinking that maybe it
would be more appropriate to have a pull system. Where you distribute a
description file with an application and the application pulls a
specific module version for its use. That way changing a module
wouldn't necessarily break it and the application developer could
control which version of which modules it uses including the meta tag
"latest". It shouldn't be difficult either building a complete module
template if you use some relatively simple form that "all" single file
modules could work with.

on the other hand, I may have just reinvented parts of eggs.

---eric