Closed riccardoporreca closed 1 year ago
Name | Link |
---|---|
Latest commit | fa8434d59a15b99cc2f92b5bf5d42f2e00709e73 |
Latest deploy log | https://app.netlify.com/sites/conda-lock/deploys/64a9f27ef234d500084b169d |
Deploy Preview | https://deploy-preview-448--conda-lock.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
See how the jobs are correctly failing given the failing tests, as opposed to e.g. https://github.com/conda/conda-lock/actions/runs/5466015810/jobs/9950322426#step:6:1001
As for the failing tests, they seem to be all related to pydantic, and started to appear following the 2.0 release: https://docs.pydantic.dev/2.0/migration/
Most errors are about virtual package specs:
validation error for VirtualPackageSpec
E subdirs.linux-64.packages.__glibc
E Input should be a valid string [type=string_type, input_value=2.17, input_type=float]
and could be addressed by quoting versions, e.g. __glibc: "2.11"
instead of __glibc: 2.11
.
The other relevant failure is
> raise JSONDecodeError("Expecting value", s, err.value) from None
E json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
perhaps related to
Due to performance overhead and implementation complexity, we have now removed support for specifying json_encoders in the model config.
Happy to include any recommended fix in this PR
See also https://github.com/pydantic/pydantic/issues/6375
Perhaps a tactical solution for now is to stick to pydantic >=1.8.1,<2.0
I'd rather try and support Pydantic v2.
I wonder how easily we can get rid of frozensets. I might be missing something, but when I occasionally use sets for internal manipulations, I prefer casting the result to a list with sorted
before returning, especially for determinism since sets get their orders scrambled, e.g. #450. If immutability is demanded by the type checker, then I cast the sorted list to a tuple.
I'm not sure if this paradigm would break down at some point when applied to conda-lock here, but that'd be my idea for how to solve it. What do you think?
@maresb, I looked a bit closer into the JSONDecodeError
, which I was maybe a bit too quick to attribute to Pydantic V2.
I could reproduce the error locally and here is what I see as proc.stdout
in dryrun_install: DryRunInstall = json.loads(proc.stdout)
, where the first line No package record found!
is clearly no valid JSON!
Not sure however where this could come from
No package record found!
{
"actions": {
"FETCH": [
{
"build": "py39hb9d737c_1",
"build_number": 1,
"channel": "https://conda.anaconda.org/conda-forge/linux-64",
"constrains": [],
"depends": [
"python >=3.9,<3.10.0a0",
"python_abi 3.9.* *_cp39",
"libgcc-ng >=10.3.0",
"typing-extensions >=3.7.4.3"
],
"fn": "pydantic-1.9.0-py39hb9d737c_1.tar.bz2",
"license": "MIT",
"md5": "5e0
[continues]
This is in fact even visible in the workflow log, e.g. https://github.com/conda/conda-lock/actions/runs/5495255879/jobs/10014527957?pr=448#step:6:400
s = 'No package record found!\n{\n "actions": {\n "FETCH": [\n {\n "build": "pyha770c72_0",\n "buil...emp/tmpztcgmr04"\n },\n "dry_run": true,\n "prefix": "/home/runner/work/_temp/tmpztcgmr04",\n "success": true\n}\n'
Thanks @riccardoporreca, I actually simultaneously came to the same conclusion. I'm not sure what to make of it, but I opened https://github.com/mamba-org/mamba/pull/2662 to hopefully eventually gain some clarity.
I was unable to reproduce locally, so it's really great that you can! Any chance that you could set a breakpoint at conda_lock.conda_solver
line 495 and see if you can figure out what's going on? In the debug console, I recommend running shlex.join(proc.args)
to get the exact command being executed.
It'd be nice to get to the bottom of this warning, but in case we can't maybe we should just ignore it as per my commit. (Not an ideal solution, so I hope we can do better.)
But now I'm actually a bit nervous about Pydantic. It seems like v2 has some big changes, and we don't have a major version pin.
I was unable to reproduce locally, so it's really great that you can! Any chance that you could set a breakpoint at conda_lock.conda_solver line 495 and see if you can figure out what's going on?
I was reproducing the steps of the test workflow for creating the environment and installing from requirements.txt. Ultimatelty, there is something in the logic leading to the print statement in https://github.com/mamba-org/mamba/blob/c46647a8807b5d4812b25c199754f4bbe904b679/mamba/mamba/utils.py#L384-L398, so I fully agree to raise the flag to mamba
But now I'm actually a bit nervous about Pydantic. It seems like v2 has some big changes, and we don't have a major version pin.
I can fully understand that!
Debug info:
shlex.join(proc.args)
"/home/riccardo/miniconda3/envs/test-env/bin/mamba update --override-channels --channel conda-forge --channel file:///tmp/tmpjqbwoa0p -p /tmp/tmpagnu7aom --json --dry-run 'pydantic >=1.9.0,<1.9.1'"
To help reproducing the issue, here is the outcome of conda list -p /tmp/tmpagnu7aom --explicit
# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: linux-64
@EXPLICIT
https://conda.anaconda.org/conda-forge/linux-64/_libgcc_mutex-0.1-conda_forge.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/ca-certificates-2023.5.7-hbcca054_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/ld_impl_linux-64-2.40-h41732ed_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/libstdcxx-ng-13.1.0-hfd8a6a1_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/python_abi-3.9-3_cp39.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/tzdata-2023c-h71feb2d_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/libgomp-13.1.0-he5830b7_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/_openmp_mutex-4.5-2_gnu.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/libgcc-ng-13.1.0-he5830b7_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/libffi-3.3-h58526e2_2.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/libzlib-1.2.13-hd590300_5.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/ncurses-6.4-hcb278e6_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/openssl-1.1.1u-hd590300_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/xz-5.2.6-h166bdaf_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/libsqlite-3.42.0-h2797004_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/readline-8.2-h8228510_1.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/tk-8.6.12-h27826a3_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/zlib-1.2.13-hd590300_5.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/sqlite-3.42.0-h2c6b66d_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/python-3.9.6-h49503c6_1_cpython.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/click-7.1.2-pyh9f0ad1d_0.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/itsdangerous-1.1.0-py_0.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/markupsafe-2.0.1-py39h3811e60_1.tar.bz2
https://conda.anaconda.org/conda-forge/linux-64/pydantic-1.7-py39h07f9747_0.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/setuptools-68.0.0-pyhd8ed1ab_0.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/werkzeug-1.0.1-pyh9f0ad1d_0.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/jinja2-2.11.3-pyhd8ed1ab_2.tar.bz2
https://conda.anaconda.org/conda-forge/noarch/flask-1.1.4-pyhd8ed1ab_0.tar.bz2
Thanks for the debug info! I would have expected to see No package record found!
though. Any idea why it's not showing up when you run the command by hand? I have to sign off for the night.
Thanks for the debug info! I would have expected to see
No package record found!
though.
Oh, I do see the same if I execute the same command manually, even w/o --dry-run
. Hopefully you can also reproduce locally by creating and environment based on the EXPLICIT
package list and the run the mamba update
command on that environment.
Btw, I could also extract installed_pkg_recs
that is looped over in mamba.utils
and triggers the message:
Actually, I think the problem is with to_unlink
, which is
[('https://conda.anaconda.org/conda-forge/linux-64', '')]
and as such pkg
in the loop is ''
!
Calling it a night too!
Interesting, my shlex.join(proc.args)
command ends with 'pydantic 1.7'
rather than your 'pydantic >=1.9.0,<1.9.1'
. I can reproduce it by switching to the latter.
So now I'm wondering why we have different version specifications. On my side, following it up the stack, in conda_lock.make_lock_files
line 328 I have src_files=['.../environment-preupdate.yml']
as an argument to make_lock_spec
. This gives me a LockSpec with
[dep.version for dep in lock_spec.dependencies["linux-64"] if dep.name == "pydantic"] == ['1.7']
This propagates down the stack via conda_lock
L380, conda_lock
L782, conda_lock
L706, conda_solver
L148, conda_solver
L490.
I'm going to merge this in order to have a working main
, but I'm still interested in pursuing this further.
I'm still interested in pursuing this further.
@maresb, I have found indications of the issue appearing with mamba 1.4.6 (released June 30), and indeed failures appeared in the last week or so. Let me pursue this further, I will report my findings and free up some of your precious time for other conda-lock topics (like pydantic V2 or vendored poetry updates ;)) or for some quality Sunday time :)
I have created #452 to follow-up on the matter
Should fix #447
This is done by Enabling fail-fast bash behavior, see https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference
Description