Clean up buildout.cfg scripts

16 views
Skip to first unread message

Tiago Freitas Pereira

unread,
Jul 12, 2016, 5:08:42 AM7/12/16
to bob-...@googlegroups.com
Hi guys,

I remembered that we have this discussion some time in the past, but I don't remember why we ended up with the current solution.

By default our buildout.cfg scripts have recipes to develop (via mr.developer) all the dependency packages (take this as an example https://github.com/bioidiap/bob.bio.base/blob/master/buildout.cfg). The build of the packages that have several C++ dependencies are usually really slow.

Why not to create a clean `buildout.cfg` with no mr.developer recipes and to create a buildout-dev.cfg developing all the packages?

I have two reasons to propose that.

1 - Most of the time you don't want to develop/debug a dependency package. If you want to do it, means that you know what you are doing, so you will properly develop the package that you want

2 - Since the good practice now it is not push code directly to bioidiap, doesn't make much sense to have the develop recipes pointing to the bioidiap repos.

What do you think?
Shall we clean up the thing?

Thanks

--
Tiago

André Anjos

unread,
Jul 12, 2016, 5:12:37 AM7/12/16
to bob-...@googlegroups.com

On Tue, Jul 12, 2016 at 11:08 AM, Tiago Freitas Pereira <tiagofr...@gmail.com> wrote:
Shall we clean up the thing?

I propose we make 2 CFG files instead:

1 - buildout.cfg with a clean configuration that re-uses all that is possible via an existing (conda) install

2 - develop.cfg with all dependencies hooked-up and to be checked-out. To avoid copying, just inherit "buildout.cfg" and extend it.

A


--
Dr. André Anjos
Idiap Research Institute
Centre du Parc - rue Marconi 19
CH-1920 Martigny, Suisse
Phone: +41 27 721 7763
Fax: +41 27 721 7712
http://andreanjos.org

Amir Mohammadi

unread,
Jul 12, 2016, 5:33:25 AM7/12/16
to bob-...@googlegroups.com
I can try and write a script to do this automatically.

Amir

--
-- You received this message because you are subscribed to the Google Groups bob-devel group. To post to this group, send email to bob-...@googlegroups.com. To unsubscribe from this group, send email to bob-devel+...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/bob-devel or directly the project website at http://idiap.github.com/bob/
---
You received this message because you are subscribed to the Google Groups "bob-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bob-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

André Anjos

unread,
Jul 13, 2016, 11:14:57 AM7/13/16
to bob-...@googlegroups.com
Maybe we should be doing this when we move software and fix the licenses. A

Manuel Günther

unread,
Jul 13, 2016, 12:01:59 PM7/13/16
to bob-devel
I have been proposing the way of having two .cfg files (a buildout.cfg and a develop.cfg) already years ago, but at that time this idea was dismissed with the justification that this would violate our intended use of the packages and would complicate things unnecessarily:
1. When developing  a package (and therewith use the package's buildout.cfg), most often we will need to develop the other packages as well. Therefore, we also enabled the debug mode by default.
2. When using a package, i.e., by implementing our own package following the packaging guide (http://pythonhosted.org/bob.extension/guide.html) we will write our own buildout.cfg anyways.

In fact, I am still very much in favor of having two .cfg files. For example, at the moment in the travis.yml files -- in order to avoid downloading and compiling dependent packages via mr.developer -- I had to add a relatively long (and maybe bogus) command line to compile the package, e.g.: https://github.com/bioidiap/bob.io.base/blob/master/.travis.yml#L24. This would be avoidable, when we use the new way of buildout.cfg (as proposed by Tiago).

Cheers
Manuel
Reply all
Reply to author
Forward
0 new messages