dankilman / clue

Cloudify Ultimate (Development) Environment
Apache License 2.0
1 stars 7 forks source link

Failures when running `clue pip install` #5

Closed jcollado closed 8 years ago

jcollado commented 8 years ago

I'm setting the development environment from scratch, so I've installed clue, run clue env and clue apply as in the documentation. Then I execute in the cloudify virtual environment clue pip install and I get failures because some of the python packages cannot be found with the expected version (4.0a5).

Looking at the first failure, what I see is that cloudify-rest-service==4.0a5 depends on cloudify-dsl-parser==4.0a5, but that cloudify-dsl-parser version is not found:

 cloudify-rest-service              | No matching distribution found for cloudify-dsl-parser==4.0a5 (from cloudify-rest-service==4.0a5)

After reviewing the inputs.yaml file that was automatically generated by clue, I see that cloudify-dsl-parser is indeed marked as a dependency of cloudify-rest-service:

  cloudify-manager:
    properties:
      project_dir: true
      resources:
      - resources
    python:
    - dependencies:
      - cloudify-dsl-parser
      - flask-securest
      name: cloudify-rest-service
      path: rest-service

and that cloudify-rest-service is a repository managed by clue:

  cloudify-dsl-parser:
    type: core

Hence, my understanding is that the pip install -e command should have been executed for cloudify-dsl-parser before the one for cloudify-rest-service and the failure shouldn't have happened because the right version of cloudify-dsl-parser would have been available at the time the cloudify-rest-service installation happened.

Is this correct or am I missing something?

dankilman commented 8 years ago

Your understanding is correct. Is clue installed in its own virtualenv as per the documentation? This sounds like a bug

jcollado commented 8 years ago

Yes, clue is installed in a separate virtual environment named clue and the clue pip install command is executed in the cloudify virtual environment that was created by clue itself.

dankilman commented 8 years ago

can you try running clue git status and verify all repos are on master branch and then run clue git pull to fetch the latest code? Afterwards, try running clue pip install again

jcollado commented 8 years ago

I've made sure that everything is up-to-date and still get the same error.

dankilman commented 8 years ago

I just installed a fresh clue in its own env, did clue env create and clue apply and then clue pip install in the newly created virtualenv managed by clue and the error you describe does not reproduce, can you try that?

jcollado commented 8 years ago

I tried to repeat the process from scratch and the errors happen even when running clue apply:

[package_installer.start] INFO: Collecting cloudify==4.0a5 (from cloudify-integration-tests==4.0a5->-r /tmp/requirements-B9Y407.txt (line 13))
[package_installer.start] WARNING: Could not find a version that satisfies the requirement cloudify==4.0a5 (from cloudify-integration-tests==4.0a5->-r /tmp/requirements-B9Y407.txt (line 13)) (from versions: 3.0, 3.1rc2, 3.1, 3.2a1, 3.2a2, 3.2a3, 3.2a4, 3.2a5, 3.2a6, 3.2a7, 3.2a8, 3.2rc1, 3.2, 3.2.1, 3.3a1, 3.3a2, 3.3a4, 3.3a5, 3.3a6, 3.3a7, 3.3rc1, 3.3, 3.3.1, 3.4a1, 3.4a2, 3.4a3, 3.4a4, 3.4a5, 3.4rc1, 3.4, 4.0a1, 4.0a3)
[package_installer.start] WARNING: No matching distribution found for cloudify==4.0a5 (from cloudify-integration-tests==4.0a5->-r /tmp/requirements-B9Y407.txt (line 13))
dankilman commented 8 years ago

This is very interesting! Right now, there are two things I can think of: 1) When you re-ran everything, did you provide a new virtualenv name? Otherwise, the process would try using your existing virtualenv. Try running rmvirtualenv cloudify before re-running clue apply or change the virtualenv name in inputs.yaml 2) Caching of git pull or something? This is far fetched, but I'm just throwing out ideas 3) If things still don't work, can you provide the full output?

dankilman commented 8 years ago

@jcollado was this issue resolved?

jcollado commented 8 years ago

I tried to reproduce the issue in a VM and it worked fine, so there must be something in my environment that is causing the problem. I'm closing the issue. Thanks for your help.