Mercurial > repos > goeckslab > pycaret_predict
comparison README.md @ 3:ccd798db5abb draft
planemo upload for repository https://github.com/goeckslab/Galaxy-Pycaret commit cf47efb521b91a9cb44ae5c5ade860627f9b9030
| author | goeckslab |
|---|---|
| date | Tue, 03 Jun 2025 19:31:06 +0000 |
| parents | |
| children | c846405830eb |
comparison
equal
deleted
inserted
replaced
| 2:0314dad38aaa | 3:ccd798db5abb |
|---|---|
| 1 # Galaxy-Pycaret | |
| 2 A library of Galaxy machine learning tools based on PyCaret — part of the Galaxy ML2 tools, aiming to provide simple, powerful, and robust machine learning capabilities for Galaxy users. | |
| 3 | |
| 4 # Install Galaxy-Pycaret into Galaxy | |
| 5 | |
| 6 * Update `tool_conf.xml` to include Galaxy-Pycaret tools. See [documentation](https://docs.galaxyproject.org/en/master/admin/tool_panel.html) for more details. This is an example: | |
| 7 ``` | |
| 8 <section id="pycaret" name="Pycaret Applications"> | |
| 9 <tool file="galaxy-pycaret/tools/pycaret_train.xml" /> | |
| 10 </section> | |
| 11 ``` | |
| 12 | |
| 13 * Configure the `job_conf.yml` under `lib/galaxy/config/sample` to enable the docker for the environment you want the Ludwig related job running in. This is an example: | |
| 14 ``` | |
| 15 execution: | |
| 16 default: local | |
| 17 environments: | |
| 18 local: | |
| 19 runner: local | |
| 20 docker_enabled: true | |
| 21 ``` | |
| 22 If you are using an older version of Galaxy, then `job_conf.xml` would be something you want to configure instead of `job_conf.yml`. Then you would want to configure destination instead of execution and environment. | |
| 23 See [documentation](https://docs.galaxyproject.org/en/master/admin/jobs.html#running-jobs-in-containers) for job_conf configuration. | |
| 24 * If you haven’t set `sanitize_all_html: false` in `galaxy.yml`, please set it to False to enable our HTML report functionality. | |
| 25 * Should be good to go. | |
| 26 | |
| 27 # Make contributions | |
| 28 | |
| 29 ## Getting Started | |
| 30 | |
| 31 To get started, you’ll need to fork the repository, clone it locally, and create a new branch for your contributions. | |
| 32 | |
| 33 1. **Fork the Repository**: Click the "Fork" button at the top right of this page. | |
| 34 2. **Clone the Fork**: | |
| 35 ```bash | |
| 36 git clone https://github.com/<your-username>/Galaxy-Pycaret.git | |
| 37 cd <your-repo> | |
| 38 ``` | |
| 39 3. **Create a Feature/hotfix/bugfix Branch**: | |
| 40 ```bash | |
| 41 git checkout -b feature/<feature-branch-name> | |
| 42 ``` | |
| 43 or | |
| 44 ```bash | |
| 45 git checkout -b hotfix/<hoxfix-branch-name> | |
| 46 ``` | |
| 47 or | |
| 48 ```bash | |
| 49 git checkout -b bugfix/<bugfix-branch-name> | |
| 50 ``` | |
| 51 | |
| 52 ## How We Manage the Repo | |
| 53 | |
| 54 We follow a structured branching and merging strategy to ensure code quality and stability. | |
| 55 | |
| 56 1. **Main Branches**: | |
| 57 - **`main`**: Contains production-ready code. | |
| 58 - **`dev`**: Contains code that is ready for the next release. | |
| 59 | |
| 60 2. **Supporting Branches**: | |
| 61 - **Feature Branches**: Created from `dev` for new features. | |
| 62 - **Bugfix Branches**: Created from `dev` for bug fixes. | |
| 63 - **Release Branches**: Created from `dev` when preparing a new release. | |
| 64 - **Hotfix Branches**: Created from `main` for critical fixes in production. | |
| 65 | |
| 66 ### Workflow | |
| 67 | |
| 68 - **Feature Development**: | |
| 69 - Branch from `dev`. | |
| 70 - Work on your feature. | |
| 71 - Submit a Pull Request (PR) to `dev`. | |
| 72 - **Hotfixes**: | |
| 73 - Branch from `main`. | |
| 74 - Fix the issue. | |
| 75 - Merge back into both `main` and `dev`. | |
| 76 | |
| 77 ## Contribution Guidelines | |
| 78 | |
| 79 We welcome contributions of all kinds. To make contributions easy and effective, please follow these guidelines: | |
| 80 | |
| 81 1. **Create an Issue**: Before starting work on a major change, create an issue to discuss it. | |
| 82 2. **Fork and Branch**: Fork the repo and create a feature branch. | |
| 83 3. **Write Tests**: Ensure your changes are well-tested if applicable. | |
| 84 4. **Code Style**: Follow the project’s coding conventions. | |
| 85 5. **Commit Messages**: Write clear and concise commit messages. | |
| 86 6. **Pull Request**: Submit a PR to the `dev` branch. Ensure your PR description is clear and includes the issue number. | |
| 87 | |
| 88 ### Submitting a Pull Request | |
| 89 | |
| 90 1. **Push your Branch**: | |
| 91 ```bash | |
| 92 git push origin feature/<feature-branch-name> | |
| 93 ``` | |
| 94 2. **Open a Pull Request**: | |
| 95 - Navigate to the original repository where you created your fork. | |
| 96 - Click on the "New Pull Request" button. | |
| 97 - Select `dev` as the base branch and your feature branch as the compare branch. | |
| 98 - Fill in the PR template with details about your changes. | |
| 99 | |
| 100 3. **Rebase or Merge `dev` into Your Feature Branch**: | |
| 101 - Before submitting your PR or when `dev` has been updated, rebase or merge `dev` into your feature branch to ensure your branch is up to date: | |
| 102 | |
| 103 4. **Resolve Conflicts**: | |
| 104 - If there are any conflicts during the rebase or merge, Git will pause and allow you to resolve the conflicts. | |
| 105 | |
| 106 5. **Review Process**: Your PR will be reviewed by a team member. Please address any feedback and update your PR as needed. |
