-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[MNT] installing task via make #655
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
base: main
Are you sure you want to change the base?
Conversation
|
@fkiraly I am a big fan of task, see https://taskfile.dev/. Here we expose a make install-task. Task is like make on steroids. |
|
Various other jobs will be added to the Makefile |
fkiraly
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Could you kindly explain this to me like I am 5 year old, who would use the task framework under which circumstances?
Do we intend this to be purely developer facing?
|
Another note, also discussed in #658 - |
|
@fkiraly task is used by make and could also be used by the user directly. However, I tend to abstract it away by a layer of make above. I am aware make is not system independent but even the Windows users can make it happen. I think the best chance of using that kind of functionality. |
|
task is also used at various places in the ci/cd framework without using make in between |
|
If we want to use It is true that, for instance, windows users can set it up, but it is behind a wall of complexity that we cannot assume users will get through just to run our code. |
|
I have no problem to hit dem directly with uv and uvx. I see make as only one way into the project. There are other routes, e.g. task or directly from the command line with uv tools |
fkiraly
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, ok - but then we need to document all this.
(I think it is "going too deep" in the task/make layer, but if you would like this, I would not mind - as long as you document it for other devs)
merges all PR CI jobs into one workflow, which allows gating and conditionals. Also makes all workflows conditional on basic code quality checks to avoid unnecessary runs.
…PyPortfolio#662) * adds a CI job, `pytest-nosoftdeps`, to test the package without soft dependencies. * isolates soft dependency `matplotlib` in tests and the plotting module * isolates the `ecos` dependency almost entirely. There is one default that remains, which is deprecated and scheduled for removal in 1.7.0. * adds `scikit-base` soft dependency (without further dependencies) to manage soft dependencies This is also useful to check whether soft dependencies are properly isolated.
…olio#675) restores the `requirements.txt` for downwards compatibility
|
I think it is too complicated for both the users and us. The code should be short and easy to read, the installation should be simple, and the dependencies should be kept to a minimum |
I recommend to checkout the branch and then hit it with "make". This functionality is not part of the "release" as in release of the package. But it can be very helpful during local development. |
|
The installation is actually as easy as "make install" after your git clone. Make install installs task + uv/uvx. It then creates a virtual environment (using uv). "make test" would run all those tests defined and "make fmt" would run ruff etc. Task is somewhat obsolete as all this functionality could be hidden in Makefiles but Makefiles are just too hard to deal with in 2025. |
Removed MARIMO_FOLDER variable and commented out logging variables.
Removed build step for Hatch from the build configuration.
We install task using a Makefile. For task please see https://taskfile.dev/
It's a lot more pleasant to work with task instead of make.