![]() Where things tend to go wrong is everything that comes after: installing further packages in the venv and/or the conda env, attempting to update one or the other, installing duplicate packages in one or the other, activating one but not the other, installing packages with incompatible binary deps, etc., etc. Am I missing something?īecause all that is being tested is just that Conda-installed packages in the outer Conda env can be imported inside it’s Python with the venv when -system-site-packages is set on creation and both envs are activated, in the correct order. I just tried this (again), and it seemed to work fine. Which I suppose, circling back, is pretty relevant to think about here-while I remain a strong advocate of teaching users (how to) use environments early and often, due to the countless times I’ve seen users struggle with the aftermath of not doing so, it is equally important that we make them as easy and painless to use as practical if we are requiring them. This is especially when those students are typically already busy and often come to me tired, frustrated and just want to get their project/research done and go home, for whom Python is but one means to an end. In fact, even the basic concept of what an environment is and why you should always use one is a difficult one to teach for the first time to students who are graduate-level scientists but with limited programming backgrounds-like I struggled with doing for a student just this Friday, who had run into issues with her base environment. and not programmers, and thus don’t have the knowledge and experience to know this (because many/most of the people they’re learning from don’t know themselves, because no one taught it to them). The unfortunate truth is that many/most “regular” Conda users are students, scientists, engineers, analysts, etc. That 's the reason I originally brought up the above-the real harm is pip install-ing into base, and if that could be prevent by default (with EXTERNALLY-MANGED or this PEP) without interfering with pip install-ing into non- base envs (or maybe adding an opt-out warning) then that would be a big win for Conda users, IMO (considering how many bork their whole Conda install because of it). And if things do go wrong, it is cheap to remove and recreate the env- so long as it is not base. However, it is necessary for using PyPI-only packages, editable installs and various other scenarios, and can typically be avoided if you are careful, know what you are doing and understand the basic mechanics involved (namely, installing only “tip-of-the-stack” packages with pip, and avoiding further updates to the existing env). If conda does set sys.base_prefix != sys.prefix, what’s going to go wrong if we just say pip can install into such environments, and will need an override to install if sys.base_prefix = sys.prefix? Ultimately, isn’t it just the case that pip/virtualenv and conda interact a bit uncomfortably, and we’re trying to pick where we draw the line, knowing that nothing’s ideal? And that will require conda to explain what they need that the current approach doesn’t do. ![]() If, for some reason, conda can’t use the difference between sys.prefix and sys.base_prefix the way it’s documented, then IMO we need a new definition, that is agreed between everyone. If it does, then there’s nothing more to be said - we can just use that. I don’t know if conda adheres to this approach, but if it doesn’t, then my first thought would be that they should (I’m taking your comment that conda envs are much more like virtualenvs than system envs as the basis of this view). Currently, and as part of the language definition, this is done by checking if sys.base_prefix != sys.prefix. But to work well, it would need a standard way to signal “this is a user-activated environment”. That sounds like a useful idea to have independently of this issue. By generalizing whatever you do to “user-activated environments” (I’d quite like the latter)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |