nexedi / slapos.buildout

@jm @rafael @kazuhiko is my understanding correct ?

some more upstream references: https://github.com/buildout/buildout/issues/420

https://github.com/buildout/buildout/pull/417

Also, because this options can be defined in buildout configuration, I think we should also fix in the profiles to use:

index = https://pypi.python.org/simple

/cc @gabriel

mentioned in merge request slapos!248

mentioned in commit slapos@8a263325

I have one problem that I am not able to run tests for this merge request. I tried several ways of running tests locally which all failed.

Because upstream tests are https://travis-ci.org/buildout/buildout , I tried to push this branch to github and see the results of tests on travis ci. This is https://travis-ci.org/jerome-nexedi/buildout/builds/295169921 . There are several failures. On python 2.7: 372 tests with 12 failures, 0 errors and 0 skipped.

I also tried a build on the base of this branch , installation fail with Error: Couldn't find a distribution for 'zc.recipe.testrunner==2.0.0'. ( https://travis-ci.org/jerome-nexedi/buildout/builds/295169832 ). Which is expected now since these tests depend on pypi. At least we can see that before that patch no egg can be installed and after the patch eggs can be installed again, so it looks better after this MR.

---

Anybody knows more about the status of slapos.buildout tests ?

Tests may just be broken because published version of setuptools is different, something similar to what happened in https://github.com/buildout/buildout/issues/398 ( but errors I had seems different )

The test failures you are a known issue with one of the last commits. Changes were done without updating tests accordingly. A bigger issue is that we have no automated test suite for this project.

mentioned in commit eb27c486

Status changed to merged

Is it useful to make a new release of slapos.buildout with this change now ? Or is slapos!248 enough for the moment ? The problem with new releases of slapos.buildout is that it causes a lot of rebuilds in our test nodes.

We can release and upgrade version on slapos.git on a Friday night, in this way we leave rebuilds for the weekend.

Anybody knows more about the status of slapos.buildout tests ?

The test failures you are a known issue with one of the last commits. Changes were done without updating tests accordingly. A bigger issue is that we have no automated test suite for this project.

Of the 12 failures, 1 is fixed by 860da6f4 and all others are due to ca6a2f94.

Now we have a test suite (BUILDOUT). See also slapos@f6ae8b6c.

Now we have a test suite (BUILDOUT).

Thank you!

Is it useful to make a new release of slapos.buildout with this change now ? Or is slapos!248 enough for the moment ?

For installing softwares, it seems it's OK ( I had to apply the same changes as slapos!248 in a project profile though).

But, I see slapos.cookbook test is failing .

on stdout

Reading http://pypi.python.org/simple/pytz/
Couldn't retrieve index page for 'pytz'

The traceback is:

======================================================================
ERROR: test_push (test_pbs.PBSTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/slapgrid/slappart7/srv/testnode/ij/inst/test0-0/parts/slapos.cookbook/slapos/test/recipe/test_pbs.py", line 41, in test_push
    recipe = self.new_recipe()
  File "/srv/slapgrid/slappart7/srv/testnode/ij/inst/test0-0/parts/slapos.cookbook/slapos/test/recipe/test_pbs.py", line 38, in new_recipe
    return pbs.Recipe(buildout=buildout, name='pbs', options=options)
  File "/srv/slapgrid/slappart7/srv/testnode/ij/inst/test0-0/parts/slapos.cookbook/slapos/recipe/librecipe/genericslap.py", line 42, in __init__
    GenericBaseRecipe.__init__(self, buildout, name, options)
  File "/srv/slapgrid/slappart7/srv/testnode/ij/inst/test0-0/parts/slapos.cookbook/slapos/recipe/librecipe/generic.py", line 64, in __init__
    self._ws = self.getWorkingSet()
  File "/srv/slapgrid/slappart7/srv/testnode/ij/inst/test0-0/parts/slapos.cookbook/slapos/recipe/librecipe/generic.py", line 79, in getWorkingSet
    requirements, ws = egg.working_set()
  File "/srv/slapgrid/slappart7/srv/testnode/ij/soft/ce5614af7b91100cbbb4b78a2897e25c/eggs/zc.recipe.egg-2.0.3+slapos003-py2.7.egg/zc/recipe/egg/egg.py", line 118, in working_set
    patch_dict=patch_dict)
  File "/srv/slapgrid/slappart7/srv/testnode/ij/soft/ce5614af7b91100cbbb4b78a2897e25c/eggs/zc.buildout-2.5.2+slapos010-py2.7.egg/zc/buildout/easy_install.py", line 1060, in install
    return installer.install(specs, working_set, patch_dict=patch_dict)
  File "/srv/slapgrid/slappart7/srv/testnode/ij/soft/ce5614af7b91100cbbb4b78a2897e25c/eggs/zc.buildout-2.5.2+slapos010-py2.7.egg/zc/buildout/easy_install.py", line 869, in install
    self.build(str(req), {}, patch_dict=patch_dict))
  File "/srv/slapgrid/slappart7/srv/testnode/ij/soft/ce5614af7b91100cbbb4b78a2897e25c/eggs/zc.buildout-2.5.2+slapos010-py2.7.egg/zc/buildout/easy_install.py", line 902, in build
    % str(requirement))
UserError: Couldn't find a source distribution for 'pytz'.

the way getWorkingSet instanciate a zc.recipe.egg.Egg on the fly uses the default value from buildout.

So releasing a new buildout and making sure it's used there should fix this problem.

[edit: added this last sentence]

Good to know. I've just released it. I'll update slapos.git this evening.

We are still using buildout1 in some of our projects... Is it worth backporting to buildout1 branch and releasing a new legacy version ?

People must stop using buildout 1. Otherwise, it's a never ending story. I already warned a previous time that anyone maintaining buildout would forget them. They can also add the index = line to their project software.cfg.

mentioned in commit jerome/slapos@84d614d1