Any plan of supporting conda for the non-scientific community? #7671
Comments
This is not the case. I think you must've either installed miniconda over the top of anaconda or just installed anaconda. |
kalefranz
added
type::support
|
You've definitely gotten the Anaconda installer somehow (maybe from https://www.anaconda.com/download ?) rather than the Miniconda installer. The Miniconda installers are located at https://conda.io/miniconda.html. Miniconda is the way to bootstrap just conda and its dependencies, which happens to include a python interpreter at the moment (which is why there's a Miniconda2 and Miniconda3), but might not always. |
|
Conda is heavily used in many enterprise production systems. https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/ is a good example. |
|
@kalefranz Hi, your answer is very encouraging for us, more so as we were thinking that Conda is heavily biased towards scientific community. But first, let me clarify what we did, there may be a problem with the miniconda release.
Here, you will see the installation of ipython, matplotlib, tornado, etc, which I was mentioning as not needed for us. And as mentioned early on, I crosschecked that we installed miniconda py 3.6. Do let us know if something is wrong. |
|
Which ? |
|
Re-ran your workflow in a linux docker container, and I get expected results. |
|
I have createv 2 new envs and the output of 'pip freeze' is different for py 2.7 and py3.7. Attached below are the logs. And below is with py3.7, where the output is similar as your's. As you see above, the pip freeze o/p of both the envs are diff (with being a part of the respective env). I had also not installed tornado pkg in either of the envs, but it is importable in py2.7. In your setup, did you install the miniconda3 from the release version available online? (I had used it the switch '-u', to install in precreated dir). I can remove miniconda and install again, but I don't find how that will be different. |
|
Hi @kalefranz, can you keep this issue open? |
|
You're probably running into #7173. This is really a pip and python issue, not a conda issue. Check the contents of I'll re-open, but I really need you to demonstrate what conda is doing incorrectly in any of your workflows. Start with a standard docker container, using |
|
@kalefranz I will look deeper into #7173. I problem I have is installation of unwanted packages, like tornado=5.1, jupyter, ipython, etc, which we do not need on our dev/production platform. The other problem is not able to install a lower version of tornado=3.1.1 to importing it successfully -- it loads 5.1. I will provide you reproduceable steps with docker. We haven't yet used docker and I need to understand and set it up, prior to creating it. |
|
Hi @kalefranz thanks for the lead to ~/.local/lib/python27. I do find now that those extra pkgs (ipython, jupyter, tornado=5.1,send2trash etc) showing up on mc3 env were existing only in ~/.local/lib/python2.7, as you pointed out. I had those selected pkgs installed on my host's native python using pip with '--user' switch. I have now also tested that removing/installing back those pkgs on my native python using pip with '--user' control their availability in my mc3 py2714 env accordingly, as shown below: However, NOTE that this issue doesn't exist with our pythonbrew/pip/virtualenv environments, which we have been using for the last couple of years, in both dev and production. That is why those pkgs didn't show up on our work envs, but first when I tried mc3. As shown above, the problem with pkgs existing in ~/.local/lib/python2.7 doesn't show up in our pythonbrew/virtualenv environment. So, maybe conda can handle this issue as well? |
|
As you can see by #7173 and back to #448, this is a contentious, long-standing issue. There's no clear agreement on how to solve it. The issue is complicated by the fact that this really isn't a conda thing at all; it's all part of the python interpreter. Of course we can actively patch this behavior out of the python interpreter in the python that conda installs, but changing behavior like that to something we don't "own" is always incredibly controversial. For your use case right now, I would recommend setting the My thoughts on where we're headed in general on this topic... For activated non- |
|
As an aside...
which community/communities do you feel most associated with? |
|
We are an ecommerce startup, with the complete ecommerce stack developed from scratch. We therefore work mostly with the tornado/redis/mysql/.. communities, but most of the other components are developed in house. Personally I am also in stock analysis, in my off times. That's where I had tried out the ipython/jupyter/matplotlib/.. packages. We typically prefer minimal environments to work with. It's nice to have many packages, but as a list, where we can search and refer/use as and when needed. That way, it helps avoiding distractions. I think miniconda3 is mostly fitting there well. |
|
Hi @kalefranz For our use case (mentioned in last post), we find that 'conda-forge' is a better repo for us as it has many of the pkgs that we use (though not all) compared to the default pkgs/[main|free|r|pro]. But the latter has a few pkgs with newer versions, comparatively. We were thinking of using both -- conda-forge and the default ones. However, we notice that pkgs from one of them do not cowork with those from the other. Aren't they supposed to? Here, I installed python-2.7.15 from conda-forge. Then wanted to update openssl pkg from defaults which has a newer version. But, it wants to downgrade the ca-certificates and certifi pkgs, as the default repos have lower version. This looks quite strange. Are we missing something? If this is how it's expected to be, and if we have migrate from our current pythonbrew/venv to conda, then seems like the only option is to not use any of the repos, but build our own local ones, from downloaded respective pips. Any other better option in this case? |
|
Hi @kalefranz Can you have a look at our last msg? We are trying to understand if dependencies across channels are expected to cowork -- we found otherwise. Thanks. |
|
You may find the thread at #7684 informative. |
|
I think this issue can be closed, but a note to the OP, and anyone else reading this issue in the future:
|
|
Hi there, thank you for your contribution! This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this issue to remain open please:
NOTE: If this issue was closed prematurely, please leave a comment. Thanks! |
|
Hi again! This issue has been closed since it has not had recent activity. NOTE: If this issue was closed prematurely, please leave a comment. Thanks! |
github-actions
bot
added
the
stale::closed
We came across Anaconda yesterday, while trying to migratate our production s/w from py2 to py3. We like the ease of using it.
#1 We installed miniconda3 and find that there are many packages installed that we don't want. For eg: ipython, ipykernel, jupyter, matplotlib, etc. We actually don't use these and would like to have an installation where these packages are not installed by default, more of a bare and clean environment to start with. Is that possible?
#2 We find that tornado=5.1 is installed. For our production version, we use an older one, tornado=3.1. We installed it, however, there seems to be some path issues, and tornado 5.1 gets imported.
How to install and use an older version of an already installed package?
Will be really glad if you can help us with these info. If things go smooth, we would be inclined to use it on our production server.
Best.
I'm submitting a...
Current Behavior
Steps to Reproduce
Expected Behavior
Environment Information
`conda info``conda config --show-sources``conda list --show-channel-urls`The text was updated successfully, but these errors were encountered: