On 23/04/2019 16:49, Jeremy Huntwork wrote:
> On Tue, Apr 23, 2019 at 9:47 AM Pierre Labastie <[email protected]>
> wrote:
>>
>> Forgotten point above:
>> - Create an organization on github with name (tentative) automate-lfs:
>> it will contain the jhalfs repo, of course, but could also host
>> experimental versions of the books, with xml added (or modified) in
>> order to make the scriptlet generation easier (LFS is already good in
>> this respect, BLFS is not, CLFS is intermediate...). All this will
>> depend on manpower (hmm, don't want to exclude women, of course, maybe
>> should use "humanpower"?). Note that the original idea of ALFS (creating
>> a DTD for xml based GNU-linux distribution builds) is not what I have in
>> mind, hence the proposal for a different name.
>
> Sounds great!
>
> Your description brings up a few thoughts that I have been
> contemplating for a little bit:
>
> 1. Do you have in mind supporting more advanced/alternative build methods?
>
> For example, in Mere Linux, I've replaced all chroot actions with
> containers. Having a generic automated system that can help support or
> drive ideas like that would be interesting.
>
> 2. Moving away from shell scripts?
>
> Shell scripts are great, and I admit I enjoy writing them. However,
> they are hard to test. Specifically, they're really hard to unit test
> in a meaningful way. And, of course, as the requirements and
> complexity of the tool grows, the nicer it is to work with a more
> modern and flexible language.
>
> So I've started exploring the idea of gradually swapping out the shell
> bits with Python and doing it in a Test Driven Development style. I
> have a little boilerplate setup that looks promising. Specifically,
> there's a few places that I think a move to Python might really help
> with:
>
> * Using a library like https://github.com/ulfalizer/Kconfiglib to
> avoid in-source menu code. All you would need is the Config.in file.
> * Using either built-in or third-party XML libraries, I believe we
> could make the command extraction easier and avoid XSL stylesheets
> entirely.
> * Better download management, caching, verification of sources. e.g.,
> https://2.python-requests.org//en/v0.10.6/user/advanced/#asynchronous-requests
> * Packaging, versioning and distribution becomes easier via pip and
> setuptools. Some of the host pre-requisites would be a little less, or
> easier to manage because pip will track and install the required
> dependencies of the tool.
> * Testing, of course. The boilerplate I have uses flake8
> (http://flake8.pycqa.org), pytest (https://docs.pytest.org) and
> coverage (https://coverage.readthedocs.io) all driven by tox
> (https://tox.readthedocs.io).
>
> 3. CI/CD?
>
> The move to Github opens up some doors around Continuous Integration
> and Continuous Delivery that may be really interesting to explore.
> Have you thought about this at all, even if in a limited way? For
> example, having pull requests trigger automated syntax/linting checks
> or even unit tests if we get that far. Or, periodically triggering
> some automated builds for testing/reporting purposes.
>
> I could write more, I tend to have a lot of ideas. That can be both a
> good and bad thing. :) But I'll leave it there for now.
Wow, what a program :)
Maybe I should just try to make it clearer what I think this organization
should aim at. Nothing really incompatible with what you say, but maybe not
going as far into some directions:
- The main aim of the tools developed in this organization, is to take
existing {,C,B,anything}LFS books (referred to as "the books" in the
following), and generate scriptlets from them, with a way to run those
scriptlets in the right order. They can serve to build a GNU linux system, but
also to test the books' instructions. The scriptlets may add instructions to
use a package manager. It may also be possible to develop a dedicated package
management system in this organization, if it is found that the existing ones
do not fit all the needs.
- The aim is not to write the books themselves. But people in this
organization may ask the authors of the books to add some visible or invisible
(xml tags such as sect1info, or attributes such as remap or role) text that
can be used by the tools in this organization to ease the conversion. Also,
there is nothing forbidding people in this organization to be authors of some
books.
- Presently the tools in this organization take books written in DocBook-4.5
xml as input. This is not necessary: tools to accept books written in other
markup languages may be developed. There are two conditions for that: (i)
somebody wants to write the tools, (ii) there exist viable books written in
this other language. Viable means there is good chance they get maintained for
a long time. When a book (think HLFS) stops being maintained, all the effort
done to write a tool to use it is just lost.
Note: the above is written in a somewhat definitive manner, because it is
easier for me than using should, would, etc everywhere. But this is only a
proposition. Please discuss additions or removals. But do not forget that, at
the moment, two persons, Jeremy and I, seem to want to be involved in this
project. And none of those two persons are able to say how much time they will
be able to spend on the project...
Regards
Pierre
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
