Upgrade uv.lock

[nitbharambe]

Lock file contains a version for fonttools 4.59.2 which is flagged as a vulnerability. GHSA-768j-98cg-p3fv

• Added a seed to all random (Only used at assignments of PF and SE)
• Reran all notebooks (except SE assignment solutions)

Also not sure if there is a easy + direct solution via dependabot. Check dependabot/dependabot-core#11913

[nitbharambe]

Re-ran all notebooks since a lock file is expected to work unconditionally when upgraded. (State estimation assignment gets changes which are resolved in #28 . We should merge that PR.)

The changes here should only clear out metadata.

A handy script for automating notebook runs:

find ./examples -name "*.ipynb" -not -path "*/.ipynb_checkpoints/*" | while read notebook; do
  echo "Processing: $notebook"
  uv run jupyter nbconvert --to notebook --execute \
    --inplace \
    --ExecutePreprocessor.timeout=600 \
    --ClearOutputPreprocessor.enabled=True \
    --ClearMetadataPreprocessor.enabled=True \
    --ClearMetadataPreprocessor.preserve_cell_metadata_mask='{"tags",}' \
    "$notebook" || echo "Failed to process $notebook"
done

If needed we can include as an action and/or pre-commit at this repository and/or other repositories,

[nitbharambe]

The script cannot run for notebooks which raise an exception. For that either --allow-errors argument needs to be used or an extra tag "raises-exception" needs to be added to the cell like in #1246.

Note: Clearing metadata would clear that tag too

cc. @mgovers

[figueroa1395]

Lock file contains a version for fonttools 4.59.2 which is flagged as a vulnerability. GHSA-768j-98cg-p3fv

We are now at 4.61.1 so we are safe. However, just to be extra cautious, can you pin to >4.60.2 as mentioned in GHSA-768j-98cg-p3fv. Good catch!

Also not sure if there is a easy + direct solution via dependabot. Check dependabot/dependabot-core#11913.

That I think would be the long term best solution, as we would not have to maintain it. However, as pointed out in that issue, it is still rather incomplete. For example, indirect dependencies are not handled well, and dependabot can potentially trigger unintended and unexpected major version bumps in the project which we can easily miss and that would require hacks to make it work well. For these reasons, and the fact that the fixes that are being worked on at the moment, haven't been updated in the dependably-action itself yet, I think we can work with ours for now. However, let's create an issue on the main PGM repo to keep track of this, as we should probably migrate once it is ready to do so.

Edit: To add to the above, it is also good to track this issue: astral-sh/uv#2512 (comment)

Edit 2: Perhaps @Thijss knows more about this?

The script cannot run for notebooks which raise an exception. For that either --allow-errors argument needs to be used or an extra tag "raises-exception" needs to be added to the cell like in PowerGridModel/power-grid-model#1246.

Running the script with the suggested flag (--allow-errors) worked fine locally for me. Why wouldn't this be a way to go? Seems like a clean and simple solution to automate this process.

If needed we can include as an action and/or pre-commit at this repository and/or other repositories,

I fully support this. Maybe make it run every time we do a major version bump, trigger it manually from main PGM or from here, every time we update a notebook, or weekly seem like good ideas to me. If it breaks we will actively know we have a problem.

[nitbharambe]

Lock file contains a version for fonttools 4.59.2 which is flagged as a vulnerability. GHSA-768j-98cg-p3fv

We are now at 4.61.1 so we are safe. However, just to be extra cautious, can you pin to >4.60.2 as mentioned in GHSA-768j-98cg-p3fv. Good catch!

It would not be good for maintainability to pin a 2nd relation dependency (matplotlib). matplotlib is a mature enough library for us to do this manually at our end. Plus any issues with bad versions can be detected by dependabot.

Running the script with the suggested flag (--allow-errors) worked fine locally for me. Why wouldn't this be a way to go? Seems like a clean and simple solution to automate this process.

We need to identify when we break any notebook with a new feature. So allowing all errors would not be the way to go.

[mgovers]

all examples are automatically synced from the PGM repo. They should not be updated here.

Instead, maybe we need to create a GitHub action in the PGM repo that runs these notebooks

[nitbharambe]

all examples are automatically synced from the PGM repo. They should not be updated here.

Instead, maybe we need to create a GitHub action in the PGM repo that runs these notebooks

Ahh right. ill revert the example related changes. Lock file we can keep and then merge

[figueroa1395]

all examples are automatically synced from the PGM repo. They should not be updated here.
Instead, maybe we need to create a GitHub action in the PGM repo that runs these notebooks

Ahh right. ill revert the example related changes. Lock file we can keep and then merge

PF and SE examples have changes due to the random seed addition. Those should also be reverted and implemented directly in PGM, right?

[nitbharambe]

PF and SE examples have changes due to the random seed addition. Those should also be reverted and implemented directly in PGM, right?

Assignments are part of workshop notebook. Hence changes corresponding to those are alright.