add pixi.toml and lockfile #489
Conversation
Not sure about pinned commits, but in core we would just have a github action that would periodically update dependencies, I'm sure this can be made to work with the revisions as well, though I do also think we want to use branches instead of pinned commits no? |
|
You cannot refer a branch in pixi according to the options I find in the docs: https://pixi.sh/v0.27.1/reference/project_configuration/#git So I pinned commits. I can change to the url |
|
@LuukBlom think we can merge? if so can you approve? because I did the merge with main I can't be the reviewer apparently |
|
@savente93 I have some local changes for this branch that adds tasks to pixi.toml (tests/docs/buildexe, just pushed them now), and would rather merge when all tasks work as well. Also, after looking into it, using a branch is not supported by pixi at the moment, so we need to pin to commit hashes unfortunately. see prefix-dev/pixi#1206 I remember you mentioning automatically updating, the hashes. Could finishing the tasks + automating this be something you'd like to pick up? |
|
That makes sense, I'm in favor of making sure it works well first as well, I just didn't realize there were things left. I can look into updating the commit hashes, but I've also been working on removing the need to use a branch on our dependencies and making some good progress. So I think if you agree it's better to just wait until we don't have to use the branches anymore. Regardless I do agree we shouldn't merge this before we have either of those solutions |
|
Actually @savente93, using a fresh install of pixi, cloning the repo, and then the task tests: So I think it'd be good to just merge this to get pixi in there (and stop additional scope creep) and then open issues for updating the hashes automatically and getting the api docs (we dont even build this currently so this is a new addition) & build exe/installer tasks to work (currently done by 2 python scripts so should be doable, but also not required as they dont care if the env is pixi or conda). Im testing it now on wsl to see if the tests are green there as well. What do you say? |
|
If it works already, then I agree. I think it will be really nice to have this as a starting point |
moved pixi config from pixi.toml to pyproject.toml. added GUI to the pixi config. Note: Currently it assumes you to have the repos cloned next to eachother, in the future we could perhaps merge the gui code into this one so we dont have to juggle 2 repos (would also solve broken envs due to mismatching environments for the frontend and backend)
removed accidental workspace file added .env to store and load mapboxtoken
|
Closing and reopening to hopefully let teamcity see this branch |
|
replaced by #567 |
Some projects are already working with pixi.
It is a nice environment manager for conda / mamba packages that is very fast in resolving and installing packages. For now I would like to use it to install the environment.
Did some testing and messing around to get pixi and submodules working together.
The new installation workflow using pixi is described in the readme, so please follow instructions there and let me know if you run into issues.
Should be merged at the same time as frontend-PR.