Compliance concern: could rich-rst become an optional dependency?

[jlowin]

Hi @BrianPugh, Cyclopts has become a core dependency of FastMCP and we love it. Also expanding use across other Prefect projects. However, one of our users has flagged that a Cyclopts dependency (rich-rst) has a core dependency on docutils which includes GPL-licensed code. This creates a compliance friction for organizations that scan for such code. We can take some documentation steps in FastMCP to explain the transitive nature of this dependency, but given Cyclopts adoption of markdown as a default, I was curious if rich-rst might become an optional dependency of Cyclopts in the near future, which would resolve this problem for all downstream users. We need to take steps quickly to ensure that FastMCP doesn't get flagged as a liability, as enterprise adoption is ramping quickly.

Appreciate your thoughts, and thank you for creating such a great library!

[BrianPugh]

I think this is something we could do; my primary concern is that this would be a breaking change, and I dont' really want to do major version releases that rapidly. However, if this is a hard-pressing issue, we could make an exception and do a v5 release. It's really unfortunate about docutils license.

Do you know if there's a way to remove dependencies via a package extras? Something like:

pip install cyclopts[no-rich-rst]

Because that would allow us to make a backwards-compatible release.

[BrianPugh]

Do you know if there's a way to remove dependencies via a package extras?

AFAICT, there's no way of doing this. I will prepare for a v5 release.

@jlowin can you give cyclopts v4 a try in your project? It should mostly (all?) work as is? But if we need any other API-breaking changes, it would be good to lump them into the v5 release. Lets target later this week (wednesday? friday?) for a (hopefully small) v5 release.

[jlowin]

I don't view this as "hard pressing" in the sense that either of our projects needs to take any kind of emergency action, as the code in question isn't actually used AFAICT (at least in FastMCP) and I'm happy to solve it via documentation in the short term.

I also don't want to catalyze an unprompted breaking release for you!

[BrianPugh]

ok thanks! Regardless, i'll get a v5-develop branch started with this change (and a few other changes). I'd certainly like to wait 2 or 3 months to let other API-breaking changes build up. I definitely don't like doing frequent major releases (puts more maintenance burden on consumers of the library).

@sanketdaru If it makes it easier on you, i could do a v5.0.0a1 pre-release (that includes removing the rich-rst dependency). That way you can explicitly specify this version in your pyproject.toml. Before that, we should probably confirm that the v5-develop branch resolves your issues. What do you think of this solution?

[sanketdaru]

Hi @BrianPugh ,
A pre-release without rich-rst sounds good as a short-term workaround. It should ideally work as FastMCP has a relaxed depdency on cyclopts https://github.com/jlowin/fastmcp/blob/c9ec1459e1d9c42ada06e000414739c8762f099c/pyproject.toml#L14

Once you've the pre-release version ready, please tag me and I shall take it in use.

@jlowin , would FastMCP make a corresponding pre-release to use cyclopts pre-release without the transitive dependency of rich-rst to help other adopters or put this as a documentation item for the short-term?

Cheers!

[BrianPugh]

I just tagged the pre-release v5.0.0a1 and published it to pypi. This should unblock @sanketdaru. Thanks for bringing this up!

[sanketdaru]

Thank you @BrianPugh and @jlowin for coming through so quickly on this compliance item. Much appreciated!

Cheers!!

[jlowin]

Thank you both for raising and helping identify a solution!