1. 10 Jun, 2016 7 commits
    • Kazuhiko Shiozaki's avatar
    • Kazuhiko Shiozaki's avatar
    • Kirill Smelkov's avatar
      zc.recipe.egg: Support environment in :develop · 11c4874f
      Kirill Smelkov authored
      Currently only zc.recipe.egg:custom supports setting environment
      variables, and zc.recipe.egg:develop does not.
      My motivation for allowing setting environment in :develop is
      There we have [wendelin.core] part which installs released egg from
      pypi, and [wendelin.core-dev] part which installs wendelin.core from
      its latest git version via zc.recipe.egg:develop .
      The problem is, wendelin.core for setup.py to work, needs git available,
      and with slapos we usually don't have git available on base system, so
      we build it by our own and do something like
          recipe = zc.recipe.egg:develop
          environment = wendelin.core-dev-env
          # wendelin.core-dev needs git to build
          PATH = ${git:location}/bin:%(PATH)s
      and the problem is environment does not currently work for
      zc.recipe.egg:develop, and thus git is not found -> build fails.
      In order to support environment in :develop, we just move environment
      setting/restoring bits from Custom to Base, and provide Base.install() which
      uses this bits. Custom & Develop .install() becomes ._install() which gets
      hooked into Base.install() .
      I've tested the patch only manually, because currently automated tests are
      broken in a lot of places for slapos.buildout and zc.recipe.egg .
      /cc @kazuhiko, @Tyagov
    • Kazuhiko Shiozaki's avatar
      zc.recipe.egg: Support on the fly pathces. · fc162f31
      Kazuhiko Shiozaki authored
      - Support on the fly patches in zc.recipe.egg by ``EGGNAME-patches``,
        ``EGGNAME-patch-options``, ``EGGNAME-patch-binary`` (or
        ``patch-binary``) and ``EGGNAME-patch-revision`` options.
      - Support on the fly patches in zc.recipe.egg:custom by ``patches``,
        ``patch-options``, ``patch-binary`` and ``patch-revision`` options.
        (options ``EGGNAME-*`` are also supported as well).
    • Kazuhiko Shiozaki's avatar
    • Łukasz Nowak's avatar
      Chomp ../ from beginging of filenames. · f1f5bca3
      Łukasz Nowak authored
      In order to have as canonical as possible paths, chomp ../ from filenames and
      recalculate base.
    • Kazuhiko Shiozaki's avatar
      Support ${:_profile_base_location_}. · 1c0fc10f
      Kazuhiko Shiozaki authored
  2. 07 Jun, 2016 3 commits
  3. 06 Jun, 2016 1 commit
  4. 06 Apr, 2016 6 commits
  5. 16 Nov, 2015 3 commits
  6. 13 Nov, 2015 11 commits
    • Reinout van Rees's avatar
      Added python 3.5 build support · caff88e3
      Reinout van Rees authored
    • Reinout van Rees's avatar
      Dropped python 3.2 as setuptools prints deprecation warnings · a4476cad
      Reinout van Rees authored
      The tests fail to run due to the deprecation warnings, so I stripped 3.2 out of travis.
      Added 3.5 instead as that's the most modern version.
    • Reinout van Rees's avatar
      Updated changelog · 13d94d86
      Reinout van Rees authored
    • Reinout van Rees's avatar
      Capitalization · 74eb44fb
      Reinout van Rees authored
    • Reinout van Rees's avatar
    • Reinout van Rees's avatar
      Using a different item for a package name · 0333f4d4
      Reinout van Rees authored
      "dist" can be a PathMetaData instance, req.key is nicer. The latter has a .lower()...
    • Reinout van Rees's avatar
      Adjusted test output to code change · 13e41011
      Reinout van Rees authored
    • Reinout van Rees's avatar
      Recording where requirements come from to debug version conflicts · d0a7f1bf
      Reinout van Rees authored
      Before you'd get a simple output like:
          Installing django.
            Installing django.
          Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)
      ... which would mean you'd have to grep in all your requirements'
      sub-requirements which package actually requires the offending "django>=1.7"
      With this change you'll get a much more helpful output right before the error:
          Installing django.
          version and requirements information containing django:
            [versions] constraint on django: 1.6.6
            Base installation request: 'sso', 'djangorecipe'
            Requirement of djangorecipe==1.10: Django
            Requirement of djangorecipe==1.10: zc.recipe.egg
            Requirement of djangorecipe==1.10: zc.buildout
            Requirement of sso: django-nose
            Requirement of sso: django-mama-cas
            Requirement of sso: django-debug-toolbar
            Requirement of sso: django-auth-ldap
            Requirement of sso: Django<1.7,>=1.4.2
            Requirement of lizard-auth-server: django-nose
            Requirement of lizard-auth-server: django-extensions
            Requirement of lizard-auth-server: Django<1.7,>=1.6
            Requirement of django-nose: Django>=1.2
            Requirement of django-nose: nose>=1.2.1
            Requirement of django-mama-cas: requests==1.1.0
            Requirement of django-debug-toolbar: sqlparse
            Requirement of django-debug-toolbar: Django>=1.7
            Requirement of django-auth-ldap: python-ldap>=2.0
            Requirement of django-auth-ldap: django>=1.1
            Requirement of translations: Django>=1.4
            Requirement of django-extensions: six>=1.2
            Installing django.
          Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)
      This makes it much easier to spot the cause (in this case
      There *are* some unrelated packages in here because I'm doing a textual
      comparison. The advantage is that it is very robust. And extracting the right
      package name from requirements without messing things up is harder to get
      right and takes more code.
    • Reinout van Rees's avatar
      Adjusted doctest to code change · 99202210
      Reinout van Rees authored
      - Adjusted the now-clearer error.
      - Removed error log message as that's now in the actual error message
    • Reinout van Rees's avatar
      Added docstring · 1a91bec6
      Reinout van Rees authored
    • Reinout van Rees's avatar
      Made the version constraint error message more clear · 52ac25dc
      Reinout van Rees authored
          The constraint, 1.6.6, is not consistent with the requirement, 'Django>=1.7'.
            Updating django.
          Error: Bad constraint 1.6.6 Django>=1.7
            Installing django.
          Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)
      The original message said "bad constraint". No, the constraint is not
      necessarily bad. It only conflicts with some other package's requirement.
      The new message tells you that "constraint" means "your own [versions]
  7. 29 Oct, 2015 6 commits
  8. 28 Oct, 2015 3 commits