Ben Rob Toolkit Tools Discussion

We adopt the Rails philosophy that we have tools create build infrastructure and working code. The code will not do anything like what the user wants but is "upgradeable" into something the user does want. In our case the user wants to create a component that does MonteCarlo integration (a familiar example):



At this point these created directories are mostly empty. scripts is populated with scripts (language to be determined) that do things like create components and add ports. The legacy directory should probably be renamed external or something. The utils directory should be folded in with scripts. The project name used in the command line will also be the SIDL package name.
(Ben thinks there'e a CcaBuildAntiPattern showing up in the thinking behind 'components/')


This creates the infrastructure incl. setServices for MonteCarloIntegrator .

- rob

---

At risk of being beaten, let me propose that the option instead be rubyesque

and that we decide from the beginning that the design intent is that there be one program named defineComponent. Can we imagine trying to explain (and manage in scripts) multiple executables all with the same name? {Spelling Alternates --env, --environment}.

Also we'll need:

and a convention that the package dir is created with matching name (mypackage here) and ports for a package are always defined in mypackage/ports unless the env file overrides the public ports location.

So then the default use case would start to look like:

Ben

---

To comment on the above: nowhere do I see a .env in the Rails work. I don't see any hidden files or worse, environment vars. I am not sure where you got this. Having said that, I think the command structure is the same as I proposed.
- Rob

---

Rails is drowning in "cached context" aka "config" files, starting from environment.rb and fanning out, as well as using RAILS_ENV for most actual development work. For a couple of examples of just how much complexity they're burying (given the 'all-ruby' assumption which removes a lot of the complexity CCA has to manage), see:
Environments in Ruby on Rails
and
Configuring Rails environments: The Cheat Sheet
and there's chaos afoot in rails, and ways around it:
My hovercraft is full of eels: Deploying to Multiple Rails Environments

The way environment.rb now works (outlinks to config/environments/*.rb gems) looks an awful lot like /etc/rc.d/ being reinvented; not a surprise since practical patterns recur.

In conclusion:
- Yes, what I'm saying in my prior examples is oriented toward keeping the default command-line usage as clean as possible.
- Yes, we're all agreed that the context has to be remembered somewhere if we're not going to make the user repeat themselves constantly.
- Torsten took the 'stuff it in a database approach', which has the advantage of being not-user-editable and the crippling disadvantage of requiring a database dependency.
- SVN/CVS/open-mpi/eclipse,... take the approach (which I am suggesting we follow) that the defaults are in a set of files/databases and the user can override the defaults in several ways. Most of these ways appear in some form in Rails and/or plain Ruby.

Ben

---

Here's how I would have the various command line tools hunt for environment information in a package+components+ports oriented system.
- The general utility programs (createPackage,createComponent, etc) are installed in one location and appear in the user's path and may be used for multiple projects at once.
- These programs consult read config information in the following order:

1. system-wide environment defaults file installed along with createPackage
2. per-user environment defaults overrides/additions in ~/.ccaenvrc, if present
3. the file pointed to by env $CCATOOLS_CONFIG, if present
4. the env file pointed to by -e command line argument, if present
5. env files in .ccaenv of the present working directory, which in the case of a component will refer upward to a project-wide config defaults file before making its own settings

- The package/project and component config files will of course be created by default and modifiable by the user (with tools or otherwise) to incorporate information about external dependencies, etc just as we discovered we must in the tutorial.

Ben

---