Added warning to inform users of known bug and issues fastcc.py

[dagl1]

• fix FastCC results differ from respective MATLAB function #1154
• description: added warning message to show that known errors are present in the fastcc code, no bugfixes
• tests added/passed
• add an entry to the next release

[Midnighter]

Thank you for the contribution 🙂. I suggest a slightly different wording of the warning.

[Midnighter]

Linting will complain about the empty line above.

[dagl1]

Sorry I think I might not understand, the original is:

""Provide an implementation of FASTCC."""

from typing import TYPE_CHECKING, List, Optional

from optlang.symbolics import Zero

from .helpers import normalize_cutoff

---

Should there not be an empty line between the built-in functions, but empty lines between: built-ins, other packages, other modules? If so I understand, otherwise I am a bit lost

[cdiener]

The warning should probably also point towards find_blocked_reactions which is slower but works.

[dagl1]

The warning should probably also point towards find_blocked_reactions which is slower but works.

Done, this is FVA based right, however doesn't use loopless FVA if I am not mistaken (I am aware that some definitions of blocked reactions don't concern themselves with loops, but in reality any isolated offshoot that forms thermodynamically infeasible loop, is still blocked, but can carry flux at the same time).?

Regarding the error, could you point me in the right direction, it is a bit unclear to me why that 1 ubuntu gives errors while the rest of the workflow was fine?

[cdiener]

Yes that does not use loopless FVA. FastCC should also allow loops I think, because all those parsimony-based methods will only avoid loops when the objective itself is not part of a loop.

You could use add_loopless first and then run find_blocked_reactions but it would be very slow.

The CI is complaining because of black. Running black on the changed file before pushing should fix this.

[dagl1]

Yes that does not use loopless FVA. FastCC should also allow loops I think, because all those parsimony-based methods will only avoid loops when the objective itself is not part of a loop.

You could use add_loopless first and then run find_blocked_reactions but it would be very slow.

The CI is complaining because of black. Running black on the changed file before pushing should fix this.

Okay I don't understand what I am doing wrong (sorry....). I ran black on the script, it reformatted a single line, and it is sucessfully committed. I feel I am wasting a lot of your time with this ;// , but also am not entirely sure where the issue comes from

[cdiener]

You are all good. Has nothing to do with you. Black got updated yet again and now formats files differently. The affected files have nothing to do with your PR so just ignore this for now.

@Midnighter We should pin the black version in tox because that is happening in almost every PR now.