Pin langchain-core dependency to prevent Settings UI crash

[dlqqq]

Description

• Fixes Error opening Settings UI #555

This PR is to be merged & released ASAP, as the latest releases are currently broken.

Context

LangChain now defines name as an instance field on the BaseLLM class we inherit from. This causes an unfortunate interaction with our name class attribute, where it causes Class.name to somehow always resolve to ... instead of the one stated in our class definition, which in turn is causing #555.

Even though the PR was only merged roughly a week ago, this affects Jupyter AI users because the change was made to the langchain-core package, and was released in langchain-core==0.1.4. langchain==0.0.350 (the current version of LangChain we use) used a loose version specifier that allowed this problematic version to be installed, despite our existing version lock on langchain.

You can reproduce this bug with Pydantic in Python like so:

from pydantic.v1 import BaseModel
from typing import ClassVar, Optional

class A(BaseModel):
    x: ClassVar[str] = "asdf"

class B(BaseModel):
    x: Optional[str] = None

class C(B):
    x: ClassVar[str] = "asdf"

assert A.x == "asdf"
assert C.x == "asdf" # <= this throws an exception

Root cause

After doing a bit of digging, I found the root cause of this bug in Pydantic's ModelMetaclass definition. The metaclass excludes any keys from showing up in cls.__dict__ if it's listed in cls.__dict__['__fields__'] (which only contains instance fields):

exclude_from_namespace = fields | private_attributes.keys() | {'__slots__'}
new_namespace = {
    ...
    **{n: v for n, v in namespace.items() if n not in exclude_from_namespace},
}

Tentatively, our next step is to rename this field in the LangChain source, as it seems to only be used for testing anyways. Then once that's released, we can revert this PR and bump our langchain version.

[JasonWeill]

Great work on this!

[dlqqq]

@meeseeksdev please backport to 1.x