[Rock-dev] [Orocos-Dev] Proposal for an update to the autoproj configuration structure

Alexander Duda Alexander.Duda at dfki.de
Mon Sep 24 11:24:52 CEST 2012


On 09/24/2012 11:19 AM, Leif Christensen wrote:
> Hi folks,
>
> the new user says:
>
> Am 24.09.2012 09:47, schrieb Sylvain Joyeux:
>> On 09/22/2012 01:34 PM, Alexander Duda wrote:
>>> autoproj/remotes:
>>> The remote package sets should not be touched by normal users therefore
>>> I would not show them in the autoproj folder.
>> That would IMO make it even more confusing as part of the configuration
>> would be hidden
> Ok, I was talking about too much advanced stuff in the folders, that can
> confuse new users using basic setups. But on the other side, one of the
> major issues I often have with autoproj/rock is, that I don't know what
> automatic magic is going on. Therefore, I would also not try to hide
> things, but try to avoid such stuff in the first place, and if that is
> not possible, make it perfectly clear, that this is stuff, one doesn't
> have to touch in most cases.
>
>>> Another reason against
>>> them is that if you are changing into the remotes folder you are also
>>> silently changing the current repository.
>> Not exactly right: you are changing the current repository when you are
>> changing into a specific remote, because they are currently symlinks.
>> Which is something I am trying to fix with the proposed changes.
>>> A possible solution would be for me to change remotes into .remotes to
>>> have a convenient way to access them for the maintainer of the remote
>>> package sets but to hide them for new uses who can get easily confused.
>> The point of the change is to not hide the remotes, but make the remotes
>> more straightforward to understand: they are listed in the main
>> configuration and look like the main configuration (no fundamental
>> difference anymore). The name is straightforward (it is listed in the
>> config file). I am a bit against hiding them as I found, along the way,
>> that hiding big parts of your configuration leads to even more confusion.
> Yep.
>
>>> File structure:
>>> Why do you stick to the YAML format? The error handling is just a pain
>>> in the ass especially after they changed from syck to psych. For me YAML
>>> is fine for everything which is generated by autoproj like the proposed
>>> options.yml but I would rather go for a nice DSL than plain YAML
>>> configuration files as in both cases I have to look up the keywords
>>> anyway but the first one gives you the ability to generate nice error
>>> messages. Furthermore you could put everything into the proposed
>>> config.rb. But I guess this is just a matter of taste.
>> The rationale was that new users only have to edit YAML files, which
>> some people find easier than Ruby code (especially since YAML is also
>> the config-file-format-of-choice for ROS tools). However, I find your
>> proposition interesting in general ... I'd like to have some more
>> feedback from "new users" (we need to ping Leif :P)
>>
> I'm not very fond of yaml. If possible, I would go for simple Key/Value
> pairs. But I guess that some sort of hierarchy/grouping ist needed?
>
> Concerning proposal 1, I like the reduced / flattened layout (but that
> you already knew ;-).
> If I understand it correctly, we won't have package-specific config
> layouts, at least not in the same file structures? I liked the idea of
> basically working in your 'own' stack exclusively and have one basic
> rock layout for all different projects you are working on. I often see
> people having multiple rock installations for every project they are
> working on with all the basic stuff included again, perhaps because
> there are too many interdependencies between basic config layout and
> their 'stack'?
>
> Concerning proposal 2, I don't get the point of merging all information
> from one config files in another one. That seems confusing and
> information duplicating?
My fault. The description on the wiki was not clear.

-> like Proposal 1 but all information from the new config.yml are moved 
into config.rb based on a domain specific language. This means there is 
only config.rb and options.yml left in the autoproj folder.
>
> Greetings,
> Leif
>
>
>


-- 
Dipl.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3



More information about the Rock-dev mailing list