I am having trouble with how CircleCI automatically detects my project type (Python) and sets up a virtual environment (venv). I’d like to disable this behavior entirely, is it possible?
Long version: I’m trying to configure and use an Anaconda environment instead of the default venv. I can install Anaconda and set the PATH variable in the “machine” section just fine to get access to the “conda” command as usual, but CircleCI’s autodetection of my project as Python means it sets up the venv after I set the PATH variable. Thus the venv path and Python gets put higher in the path order than Anaconda’s Python. Is there a way to disable automatic configuration of the venv? Something like machine:python:version:None in the YAML would work, but I don’t see any options like that. I’ve tried adding e.g. ruby, but Python is still set up. Any ideas?
I’d like to disable the whole CircleCI autodetect-magic too!
It’s very cool that CircleCI does it’s best to make the whole CI thing as smooth, easy and 1-click-ready as possible. But there are times where I would prefer a “naked” linux/OSX machine too. The reasons may range from “autodetect goes nuts” over “requirements installation IS PART of my product” to “I do such things always on my own”. So a simple “opt-out” flag in the
circle.yml would be awesome
Any update on this integration issue w/ Conda? We’re running into the same problem and are stuck at the moment. We filed an issue w/ CircleCI but no luck. They asked us to post the question to the community for help, even though we pointed them to this existing post, which describes exactly our issue. Not the best impression about this CI service so far.
I haven’t heard anything since my original post. Thanks for mentioning it affects you, as well, though – that might help bring attention to it.
disable auto-detection (partial): don’t specify a python version in your circle.yml file .
run a command (or reference an executable script) in the checkout>post stage.
run a clean install of python specifying the desired version (v2.x or 3.x) using pyenv (already installed with the image/container) .
then, you’re free to continue hating life with your likely (shit) code.
I already had no version specified in my circle.yml file, didn’t seem to help.
I had been running it in the dependencies>pre (or override) stage, which seems like it should come after checkout stage according to this:
So I don’t think moving it to checkout->post would help. Even if the order is different, the underlying problem is that the environment variable PATH cannot be set during these stages AFAIK – it must be set during the machine>envirenment stage, after which it will be overridden by the autodetection magic.
But I’m trying to set up Anaconda Python, not one using pyenv. The problem is that pyenv always takes precedence over Anaconda (or anything else I’d set up) due to when the PATH variable gets modified.
gotcha, but i’m still proposing a solution that works: from within
checkout:post, just remove pyenv altogether
$ rm -rf ~/.pyenv . in
dependencies:pre, run your commands to install conda … ended up doing this on a current project’s build after monkeying with using the existing pyenv install to no avail
Tried it, I still get:
(I’m going to try removing that directory, too, though, maybe that will work…)
~/virtualenvs did indeed work. Thanks @gregorynicholas
here’s a snippet to provide better / more complete detail of my suggested solution: https://gist.github.com/gregorynicholas/e0cf7165633be98bd2fd