Skip to content

chore(deps): bump nc_py_api to 0.30.3 - #232

Open
edward-ly wants to merge 1 commit into
mainfrom
chore/noid/py-update
Open

chore(deps): bump nc_py_api to 0.30.3#232
edward-ly wants to merge 1 commit into
mainfrom
chore/noid/py-update

Conversation

@edward-ly

@edward-ly edward-ly commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Generated via poetry add nc_py_api@^0.30.3 -E calendar. Updating other dependencies can (and probably should) be done in a separate PR.

Signed-off-by: Edward Ly <contact@edward.ly>
@edward-ly
edward-ly requested a review from janepie August 28, 2026 21:19
Comment thread pyproject.toml
Comment on lines 12 to +13
python = ">=3.11,<4"
nc-py-api = {extras = ["calendar"], version = "^0.24.2"}
nc-py-api = {version = "^0.30.3", extras = ["calendar"]}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe >=^0.30.3 can be used so normal updates update this dep automatically, not sure if that does happen in practice though.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe dependabot would be better suited for this? It looks to me it hasn't been explicitly enabled for Python packages yet.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah that works too.
I don't go that route often since dependabot creates a lot of PRs frequently. I try to only bump the deps before a release since before that it just sits in the repo unused (excluding dev setups).
but that's just a personal preference, ymmv.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, we can bump the dependencies manually too, that's fine.

@edward-ly

Copy link
Copy Markdown
Contributor Author

By the way, the integration tests are still failing on stable33 and stable34, but I'm not sure why or where the The "login-name" option does not exist. errors come from.

@kyteinsky

Copy link
Copy Markdown
Contributor

looks like the option was added here: nextcloud/server#59680 but not backported
and some more usage of the option introduced here: nextcloud/server#63555 which was backported so the definition of the --login-name option does not exist in 33 and 34.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants