Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Containerfile #397

Merged
merged 2 commits into from
Nov 13, 2023
Merged

Add Containerfile #397

merged 2 commits into from
Nov 13, 2023

Conversation

xxyzz
Copy link
Collaborator

@xxyzz xxyzz commented Nov 13, 2023

Run code in a container could solve all the environment errors. We could publish the container image to GitHub Packages so the users don't need to build the image. This could also relief the burden of compatible with older Python verisons.

@xxyzz
Copy link
Collaborator Author

xxyzz commented Nov 13, 2023

The command of installing package from pypi.org is deleted because that package is so outdated.

@kristian-clausal
Copy link
Collaborator

This seems good for those users who wish to use containers, I don't see why we couldn't have this. Is the image generation possible to automate so that upkeep of a GitHub package is hassle-free?

@xxyzz
Copy link
Collaborator Author

xxyzz commented Nov 13, 2023

Maybe just need to run two podman commands to build and upload the container image. I'll try the commands in my fork repo.

@kristian-clausal
Copy link
Collaborator

Thanks, this seems great.

@xxyzz
Copy link
Collaborator Author

xxyzz commented Nov 13, 2023

The published container image page in my fork repo: https://github.com/xxyzz/wiktextract/pkgs/container/wiktextract

@xxyzz xxyzz merged commit f66999a into tatuylonen:master Nov 13, 2023
5 checks passed
@xxyzz xxyzz deleted the container branch November 13, 2023 11:39
@empiriker
Copy link
Contributor

I always appreciate containerized applications when I just want to run an application as is. So this is a good addition. 👍

However, I don't think it solves all issues with versioning, in general. In the past, I have used wiktextract as a dependency and then overwritten or customized parts of the application and I always struggled with using a specific version of wiktextact.

In particular, I used to fix the version of wiktextract by specifying a certain commit, e.g.: wiktextract @ git+https://github.com/tatuylonen/wiktextract.git@a3665b8779ad78b045406cc7b1e9ce31876bc6b6.

The problem is that the install script of wiktextract always installs the latest version of wikitextprocessor from the repository. After a while a fresh install will result in incompatibile versions of wikitextprocessor and the commit of wiktextract.

As I understand, the containerized application won't have that problem. But in the described use case, where the wiktextract isn't run as is but used as a dependency, the container won't help.

IMO, the ideal solution would be to introduce proper versioning for wiktextract's dependecies.

@xxyzz
Copy link
Collaborator Author

xxyzz commented Nov 14, 2023

You could use pip freeze and install the packages with the --no-deps option.

I don't think we could make releases for both packages, because Wiktionary changes every day and our parser is unstable.

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.

3 participants