Recommended virtual environment methods, tools #1874
Replies: 6 comments 11 replies
-
|
Sounds like a good idea to update docs. I mostly use mamba-forge. No fuss no mess. I also use the built in |
Beta Was this translation helpful? Give feedback.
-
|
Mambaforge, zero doubt. What I love:
|
Beta Was this translation helpful? Give feedback.
-
|
I am not as aware of these issues as I should be, so thanks for the discussion. I did find the following in the license agreement:
Looks like I should be ok. Last new install I did was mini-conda with the mamba solver, which worked ok. I was thinking that we could create/publish a yaml file that covers 99% of anticipated pvlib user needs as an alternative to the full anaconda. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW although the anaconda/conda-forge indexes used to be the only reasonable option for getting a lot of fundamental data/numerics packages (esp on windows), it's a lot easier than it used to be to get everything from PyPI nowadays. That said I still like conda/mamba for creating new environments, but I almost exclusively use pip to install packages into them. But it seems like pvlib is one of many projects with an imperfect "getting started with python" page, and it's a shame for all of us to reinvent that wheel and/or reference each other. I wish some collaborative like scientific-python.org would make something like that which all of us could reference. |
Beta Was this translation helpful? Give feedback.
-
|
Dusting off this old discussion, FWIW, I now use There used to be one binary dependency, Edit to add: and of course there’s |
Beta Was this translation helpful? Give feedback.
-
|
In my experience, uv is wicked fast (esp. for complicated dependency trees,
thanks Rust!) and provides a lock file that includes all transitive
dependencies, which enables completely reproducible builds. (The lock file
may not be committed for pvlib-python since it’s a library, but it can be a
CI artifact that serves as a complete record of the build that was tested.)
Also, my understanding is that uv can replace both pyenv, venv, and pip,
while also working with likewise wicked fast companion dev tools such as
the ruff linter (also written in Rust).
Mark Campanelli
LinkedIn <https://www.linkedin.com/in/markcampanelli/>
Intelligent Measurement Systems LLC
<https://intelligentmeasurementsystems.com>
Try PVfit <https://pvfit.app> today!
…On Sat, Nov 22, 2025 at 14:28 Anton Driesse ***@***.***> wrote:
uv has been really stellar for us and we have switched all of our
infrastructure to it.
Why?
—
Reply to this email directly, view it on GitHub
<#1874 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAISX43LZYAJ722TK4722HT36DIQZAVCNFSM6AAAAACM42DKAWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMBUHA3TKMA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
Are there any plans in the works to update documentation related to virtual environments? Existing documentation favors Anaconda/conda [1] or references Astropy [1, 2], and Astropy recommends conda, virtualenvwrapper, or pipenv.
Conda:
Maybe it's just me, but Anaconda's terms are confusing for commercial users. It seems like Anaconda requires a paid license for commercial use [3], and conda is BSD-3, but I'm not sure how to install conda without Anaconda. Also, see confusing answers on the internet, like here https://stackoverflow.com/questions/74762863/are-conda-miniconda-and-anaconda-free-to-use-and-open-source. For now, I've decided not to use it at all, and I worry that this might be a hurdle for other potential commercial users.
pipenv: (recommended by Atropy)
I don't know much about it, but I've found a number of online discussions where people say it is (was?) deprecated, stale, or simply no longer "favored".
What about venv?:
It looks like venv is officially recommended by Python/PyPA for Python 3.3, and comes with a standard Python installation [4]. I don't know anything about the auther of this article [5], but they seem to make a compelling argument for venv. I've been using venv for a while now (which definitely doesn't make it an automatic good idea...) and it seems to be working ok. Should venv be referenced somewhere in the pvlib documentation?
[1] https://pvlib-python.readthedocs.io/en/latest/user_guide/installation.html#set-up-a-virtual-environment
[2] https://pvlib-python.readthedocs.io/en/latest/contributing.html#the-basics
[3] https://legal.anaconda.com/policies/en/
[4] https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/#installing-virtualenv
[5] https://www.bitecode.dev/p/why-not-tell-people-to-simply-use
Beta Was this translation helpful? Give feedback.
All reactions