Open zooba opened 1 year ago
Okay, after a bit more playing, I've managed to get an environment that basically meets my needs.
The problem is the python_abi
"package", which doesn't contain any files, but is used to constrain packages (basically, to make conda install
fail more often so you're less likely to get a broken environment).
With the following commands, I managed to get an environment that takes python_abi
from conda-forge, but has everything else from the correct locations:
> conda install python=3.10
> conda install -c conda-forge python_abi
> conda install -c microsoft playwright
> conda list
# packages in environment at C:\Users\...\envs\env:
#
# Name Version Build Channel
bzip2 1.0.8 he774522_0
ca-certificates 2023.08.22 haa95532_0
greenlet 2.0.1 py310hd77b12b_0
libffi 3.4.4 hd77b12b_0
openssl 3.0.11 h2bbff1b_2
pip 23.3 py310haa95532_0
playwright v1.33.0 py310_0 microsoft
pyee 9.0.4 py310haa95532_0
python 3.10.13 he1021f5_0
python_abi 3.10 2_cp310 conda-forge
setuptools 68.0.0 py310haa95532_0
sqlite 3.41.2 h2bbff1b_0
tk 8.6.12 h2bbff1b_0
typing_extensions 4.7.1 py310haa95532_0
tzdata 2023c h04d1e81_0
vc 14.2 h21ff451_1
vs2015_runtime 14.27.29016 h5e58377_2
wheel 0.41.2 py310haa95532_0
xz 5.4.2 h8cc25b3_0
zlib 1.2.13 h8cc25b3_0
The three commands need to be run separately, otherwise they'll each try to replace most of the environment. (The conda-forge step actually downgrades my TLS certificates to an older version, but the third step brings them back.)
So there's a workaround for users. I'm not sure there's an easy way to avoid the python_abi
dependency though, other than to compile using Anaconda packages instead of conda-forge. Clearly all the other dependencies are available.
I was looking at some other packages which we distribute over our microsoft conda channel, their Python dependency looks similar, and it seems like there is not much we can do here on our side? Where is our python_abi dependency coming from? Most likely from Python itself?
Seems like you are more of a Conda expert here than we are here, so if you have suggestions, let us know!
I was looking at some other packages which we distribute over our microsoft conda channel, their Python dependency looks similar
I never accused you of being the only culprits 😉
Where is our python_abi dependency coming from?
It comes from using conda-forge when building the package, because they make it a strict requirement. Anaconda does not, so if you build using their packages, it would still successfully install against conda-forge because all the dependencies are satisfied. It doesn't work the other way, because Anaconda can't satisfy the python_abi
dependency.
if you have suggestions, let us know
I suspect deleting this line will be sufficient: https://github.com/microsoft/playwright-python/blob/main/.github/workflows/publish.yml#L19
Possibly it needs to be replaced with defaults
, but that should be the default.
I suspect deleting this line will be sufficient: https://github.com/microsoft/playwright-python/blob/main/.github/workflows/publish.yml#L19
Possibly it needs to be replaced with defaults, but that should be the default.
I tried both, but getting this in both casese:
Unsatisfiable dependencies for platform osx-64: {'greenlet==3.0.0', 'pyee==11.0.1'}
Looks like Anaconda hasn't updated past greenlet 2.0.1 and pyee 9.0.4 for osx-x64 (list here, but be warned it's a big page).
Are those particular versions required? Or just frozen there. We can ask them to prioritise the newer versions if needed and get them added.
We usually freeze them, so that if customers install Playwright, its guaranteed that this version works for them. We had cases where dependencies were breaking us.
We are also using very often very recent versions of pyee or greenlet, since they often fix bugs which are important for our customers.
So if we would lax the version range for our published conda package, it would work with the default channel? TIL.
That sounds like a good reason, but as I said, we can ask Anaconda to accelerate their updates if there are fixes we need.
And yeah, loosening version ranges is generally a good move. Conda does a pretty good job of locking in the versions that are actually used to build a package if they matter, and allowing updates on install for those that don't. So you should be able to get the best of all worlds by not freezing the inputs and making sure that the outputs are/aren't frozen as appropriate.
Happy to take this internal to figure out how to proceed from here, you know my team alias (the obvious one).
I'm trying to add Playwright to my conda environment installed from Anaconda's repository, but it produces conflicts and/or tries to replace the entire environment.
It seems the packages published to anaconda.org/microsoft have tight dependencies to conda-forge, which means it's impossible to install the packages into a non-conda-forge environment.
For example, here's the output of a command that ought to install
python=3.10
from Anaconda andplaywright
from-c microsoft
:(As usual, I don't believe that the conflicts listed are the actual conflicts. The fact that it fails is the main point.)
If I add conda-forge as a channel, I get this proposed plan:
However I'm not able to use conda-forge packages in my environment - I have to use Anaconda's (for $place_of_work reasons).
It would probably be best if the anaconda.org/microsoft channel contained packages that work with Anaconda's repository, and then contribute a recipe to conda-forge to make their own build of playwright that works with that channel.
(An alternative would be to ask Anaconda to make their own build of playwright that works with their repository, but they'd want it in conda-forge first anyway, at which point the problem is solved.)