On 04/12/2014 19:05, Sam Thursfield wrote:
The Baserock Import tool is in a usable state. It can generate
.lorry and .morph files for many of the projects on
. Initial support for importing stuff from
is on its way shortly too.
There are a number of important improvements that I think it needs
(see the TODO file), but I feel like that the overall approach it
takes is sound, and I'm hopeful that after reading the tutorial you
will feel that using the tool sounds more attractive than the
equivalent manual process. I hope it also seems nicer than putting
.gem files directly into your production systems. (There's no reason
not to continue using 'gem' and 'bundler' during development, by the
way, I think it's only once audit and reproducibility become a
concern that the Baserock tooling becomes interesting).
The tutorial is here:
;. It's quite
long (and the plot is quite weak). Future improvements to the tool
will allow us to remove sections of the tutorial (while also making
it a bit less "hands-on", I think).
The source code is here:
An import of the core Chef client software that I did a while back
exists in this branch of definitions.git:
As this mail marks the end of the initial development phase I think
we should start using the normal review policy on this repo,
although since not many of us are familiar with the codebase yet I
think myself and Richard Ipsum should be free to +2 import tool
patches for a bit, to avoid changes getting stuck for lack of
Some comments on the Wiki page and on the README files
I'll give it a +1 anyway (if you still need one), but I think addressing
these would improve it.
Using the Baserock Import tool for RubyGems
The Baserock Import tool is available in Baserock 'devel'
See the using baserock page for how to set yourself up a devel
"'devel' systems" to "development systems" -
the development images no
longer have 'devel' in their name so using it could be confusing. The
rest of the wiki talks about 'development VMs' and the files are 'build
system images' (which is also confusing, but that's another story)
Chapter 1: Doing an import
This sort of thing is common when you try to import an unstable
version of a RubyGem: some .gemspecs will
.gemspec => `.gemspec` or
Same for other file extensions and file/directory names throughout
(./checkouts, .lorry, .foreign-dependencies, file:/// ). Whatever
convention you use, be consistent
That way you can iterate quickly when doing the manually bits of the
manually => manual
it won't update it, by default.
=> by default,
`baserock-import` won't update it. (Same for all the
'it's in that paragraph
Chapter 2: Lorrying and missing refs
[Lorry] is a tool which pulls source from various
A [Trove] system
Add the links or remove the 
They've been put into a "ruby-gems/" namespace.
It would be good if you could make that link to the footnote work
create a tag yourself named 'v5.4.3' pointing this commit:
pointing *to* this commit
Chapter 3: Generated chunk morphologies
difference in each one though: name of the Gem.
...though: the name of the Gem
Chapter 4: Non-standard projects
I'd like to think that we both got the same output. In practice,
took me a number of attempts to get to this
Too many 'it's in this para too
- use `import-tool`
Chapter 5: Cooking up a system
Chapter 6: Next steps
you might be using a [Trove]
The Import Tool uses [Lorry] in
Add the links or remove the 
The .lorry file created by the tool are directly usable
...files are... or ...file is...
send them for review in using whatever...
=> review using
At least for the Baserock project's definitions.git it's
unconventional to include the version number of a chunk in its name.
I failed to
parse the first part of this sentence :( Does it mean
"In the definitions we use in [Baserock `defintions.git](g.b.o. url), we
don't usually include the version number...."
Please will you rephrase it?
As you've written so much in the first person (which works well IMHO)
you could think about 'signing' this page with your name. It seems weird
to read about 'I' when I don't know who 'I' is :)
- Too much passive voice:
- It's possible to teach the code... => You can teach...
- For each supported package system, there should be... => For each
supported package system,the tool should create... or => You need to
- Each packaging system can have static data saved => You should
create a .yaml file containing
- The following field should be honoured by... => Most packaging
systems will honour...
the RubyGems importer
is that `baserock-import`? or even
'this import tool'? Maybe make that