Sender | Message | Time |
---|---|---|
30 Dec 2023 | ||
Ovsyanka | In reply to @Evidlo:matrix.org* It was https://github.com/libkeepass/pykeepass/pull/261 | 19:57:38 |
Ovsyanka | * It was https://github.com/libkeepass/pykeepass/pull/261 I did some experiments and as I see, When I use So, the question is - is it okay to not have build directory after the building process? As I understand that is just some temporary data | 20:03:28 |
Ovsyanka | In reply to @Evidlo:matrix.org Why do you think it is better? Don't you think it is better to eliminate possibility to have inconsistence betveen git and the source code regarding the version information? Honestly, It is harder to me to make it take version value from the version.py because I don't know yet how to do it, but I figured the workflow I described - take the version from the git and set it in the packaged version.py and package metadata. | 20:22:09 |
Ovsyanka | In reply to @Evidlo:matrix.org* Why do you think it is better? Don't you think it is a good idea to eliminate possibility to have inconsistence betveen git and the source code regarding the version information? Honestly, It is harder to me to make it take version value from the version.py because I don't know yet how to do it, but I figured the workflow I described - take the version from the git and set it in the packaged version.py and package metadata. | 20:22:26 |
Ovsyanka | * Why do you think it is better? Don't you think it is a good idea to eliminate possibility to have inconsistence between git and the source code regarding the version information? Honestly, It is harder to me to make it take version value from the version.py because I don't know yet how to do it, but I figured the workflow I described - take the version from the git and set it in the packaged version.py and package metadata. | 20:22:34 |
evidlo | I mean take the version from version.py. It will be easier because that's what I already for determining the release filename | 20:24:12 |
evidlo | * I mean take the version from version.py. It will be easier because that's what I already do for determining the release filename | 20:24:24 |
Ovsyanka | Do you know how to do it using pyproject.toml and poetry? | 20:24:50 |
evidlo | it seems the recommended way is to pull from pyproject.toml like here: https://stackoverflow.com/questions/67085041/how-to-specify-version-in-only-one-place-when-using-pyproject-toml | 20:26:33 |
evidlo | either way, not from git tags | 20:26:43 |
Ovsyanka | It is no problem to have it hardcoded in the pyproject.toml . It is easy-peasy =)We were talking about taking the version from version.py, right? And that I don't know yet how to do., | 20:29:26 |
Ovsyanka | * It is no problem to have it hardcoded in the pyproject.toml . It is easy-peasy =)We were talking about taking the version from version.py, right? And that I don't know yet how to do. | 20:29:28 |
evidlo | I don't mind it being in pyproject.toml | 20:29:46 |
Ovsyanka | The workflow I was suggesting it to have "0.0.0" version as a stub in the pyproject.toml and version.py and have it generated only for the build artifacts on the build time based on the git tag | 20:30:35 |
evidlo | I'd rather it be in pyproject.toml and everything sources it from there | 20:30:59 |
Ovsyanka | In reply to @Evidlo:matrix.orgOkay, let it be that way since you don't like git-derived versioning for some reason =) | 20:32:06 |
Ovsyanka | evidlo: what do you think about removing support for python 3.6, 3.7? They reached the EOL and current version of poetry doesn't support them. | 22:40:20 |
Ovsyanka | * evidlo: what do you think about removing support for python 3.6, 3.7? They reached the EOL (https://devguide.python.org/versions/#versions) and seems that current version of poetry doesn't support them. | 22:40:43 |
Ovsyanka | * evidlo: what do you think about removing support for python 3.6, 3.7? They reached the EOL (https://devguide.python.org/versions/#versions) and seems that current version of poetry doesn't support them, hence failed builds https://github.com/Ovsyanka/pykeepass/actions/workflows/ci.yaml | 22:41:05 |
Ovsyanka | For now I'll try to use previous version of poetry, but this is something to think of. | 22:41:43 |
Ovsyanka | And poetry 1.1.13 (the last version that supports python 3.6) doesn't support dependency groups (I used one for the sphinx dependency)... So I would like to hear from you if you gonna drop support of python 3.6 and|or 3.7 before trying to solve that. | 22:54:40 |
Ovsyanka | You can see my current work here, bu the way. I didn't prepare this fo PR yet, but it is mostly done. https://github.com/Ovsyanka/pykeepass/tree/poetry-migration | 22:55:46 |
evidlo | Looks good. I'd ask to move version, dependencies, description, authors to a [project] section instead of a poetry-specific one | 23:04:59 |
Ovsyanka | I am not sure it is possible, but I'll look closer into it | 23:05:29 |
evidlo | https://stackoverflow.com/questions/75408641/whats-the-difference-between-the-tool-poetry-and-project-tables-in-pyprojec | 23:06:58 |
evidlo | An example with optional deps: https://discuss.python.org/t/pyproject-toml-optional-dependencies-redundancy-aka-dry-extras/8428 | 23:07:48 |
Ovsyanka | In reply to @Evidlo:matrix.orgThat is what I talked about. As I understand, currently there is no way to tell poetry to use [project] instead of [tool.poetry] . Or did I read that wrong? | 23:10:20 |
Ovsyanka | If you like to read about the reasoning why it isn't support PEP-621 yet, I think this is the good starting point https://github.com/python-poetry/poetry/issues/3332#issuecomment-1793512124 | 23:31:52 |
Ovsyanka | In reply to @Evidlo:matrix.orgIs it about groups in pyproject.toml? If so, should I read that as you are not gonna drop python 3.6,3.7 for now? | 23:35:03 |
Ovsyanka | In reply to @Evidlo:matrix.org* Are you suggesting the alternative way to specify sphinx dependency in pyproject.toml without using groups? If so, should I read that as you are not gonna drop python 3.6,3.7 for now? | 23:42:05 |