Make EvaP pip-installable and publish to PyPI #2328
Conversation
niklasmohrin
had a problem deploying
to
release
GitHub Actions
Failure
niklasmohrin
force-pushed
the
pip-install-evap
branch
from
b9bd7a6
to
501bd68
Compare
niklasmohrin
had a problem deploying
to
release
GitHub Actions
Failure
|
@richardebeling Thoughts? Furthermore, if you create a PyPI account, I can add you as a co-owner of the package. (I also requested the creation of an e-valuation organization on PyPI, not sure if it will be nicer / needed, we'll see once it's processed) |
pyproject.toml
Outdated
| name = "evap" | ||
| description = "EvaP" | ||
| authors = [ "EvaP Developers" ] |
There was a problem hiding this comment.
Should we add the organization members here? Right now, PyPI displays "EvaP Developers" under unverified details, I suppose we could also just add the names which will hopefully be deduplicated then
There was a problem hiding this comment.
Looks like it won't be deduplicated, I suppose no one really cares about this, see https://test.pypi.org/project/evap/2024.10.0/ or https://pypi.org/project/black/
There was a problem hiding this comment.
I must be blind -- what section exactly would contain duplicated names? I see 5 unique user names on the black project page under "Maintainers"
I'd be fine with just putting "EvaP Developers", which will always remain correct.
Do we even need this in the pyproject.toml? I would expect that for username mapping, you need to configure this on PyPI separately anyway?
There was a problem hiding this comment.
"Ambv" is the same person as the unverified "author" (=> big projects don't care about about unverified data) and also on the evap release my name appears twice (=> it doesn't get deduplicated). Therefore, "evap developers" also seems fine to me.
We need to add something because otherwise poetry will complain :/
There was a problem hiding this comment.
Ah, I see -- I was looking for duplication inside one list. Yeah, "evap developers" 👍
niklasmohrin
force-pushed
the
pip-install-evap
branch
from
cb69e3b
to
501bd68
Compare
niklasmohrin
had a problem deploying
to
release
GitHub Actions
Failure
niklasmohrin
had a problem deploying
to
release
GitHub Actions
Failure
|
One thing we discussed in person was that we now don't really need a full checkout of the EvaP repository on production. In fact, this is a chance to move most of the (apache-)deployment files out of the main repository and into a separate repository in the e-valuation organization. @janno42 agreed that this would be a nice (while not really needed) change. The only drawback seems to be that testing the backup process in the EvaP repository will be more complicated. Currently, I believe that we would want to pin a commit of the deployment repository, for example through flake.lock, and run the tests here. I believe that we could add the backup process test logic through nix in the deployment repository and then import this test in the EvaP repository to use the updated source of EvaP. In particular, this would allow us to share the test definition and "easily" run the same tests in both repos. I am not too settled on this approach though. Thoughts @richardebeling ? |
While certainly unexpected, I think it's a funny and efficient solution, and I don't have any reasons against doing this.
Why? "Backup" essentially is "Dump database via Re (separate repo, version pinning): Adds complexity, but if there is a need for this or it helps in any way, I guess we won't die 🤷♂️ A proper release procedure with some github magic action could also be used to deliver compiled TS and SCSS files automatically, something that I dislike a bit about our current approach (necessity to have npm somewhere). (We should keep in mind though: Automation is always nice up to the point where it stops working) |
niklasmohrin
had a problem deploying
to
release
GitHub Actions
Failure
Publish on main PyPI Remove unneeded code to add `evap` to PYTHONPATH Run `manage.py` on `python -m evap` fix manage.py possibly package with hatch?
niklasmohrin
force-pushed
the
pip-install-evap
branch
from
4b3bef6
to
ee6a6e3
Compare
niklasmohrin
had a problem deploying
to
release
GitHub Actions
Failure
Closes #2303
Since we don't want to use nix in production (for example because security updates might take a long time to propagate through nixpkgs / through our github release cycle),
pip install .orpip install evapseems to be the most canonical way. This allows us to install security patches viapip install --upgrade evap.If we really need to override a dependency version beyond the allowed range in
pyproject.toml, we could also clone the repository on the production server, perform the change, and then runpip install .- I hope this won't be necessary though.The new release workflow is:
pyproject.toml, commit it, tag it, push it.The versioning scheme we agreed on is year-month-patch, for example "2024.11.0". I suppose we should take care that we don't necessarily push breaking changes like updating the Python version in a new patch.
Since upgrading to the next stable revision of EvaP is handled by pip, there is no need to the
releasebranch anymore.See
TODO:
python -m evap collect_staticto generate the static files for apache to serve should do the trick. Not sure how bootstrap fits into this yet though