path: root/python-mllint.spec

%global _empty_manifest_terminate_build 0
Name:		python-mllint
Version:	0.12.2
Release:	1
Summary:	Software Quality Linter for Machine Learning projects
License:	GPLv3
URL:		https://github.com/bvobart/mllint
Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/b7/95/624ac7b4d14cc01c49728cd7ecd717ef756502e548eeaaf9e077635fedf6/mllint-0.12.2.tar.gz

Requires:	python3-dvc
Requires:	python3-pylint
Requires:	python3-mypy
Requires:	python3-black
Requires:	python3-isort
Requires:	python3-bandit

%description
## Installation
`mllint` is compiled for Linux, MacOS and Windows, both 64 and 32 bit x86 (MacOS 64-bit only), as well as 64-bit ARM on Linux and MacOS (Apple M1).
`mllint` is published to [PyPI](https://pypi.org/project/mllint/), so it can be installed globally or in your current environment using `pip`:
```sh
pip install --upgrade mllint
```
Alternatively, to add `mllint` to an existing project, if your project uses Poetry for its dependencies:
```sh
poetry add --dev mllint
```
Or if your project uses Pipenv:
```sh
pipenv install --dev mllint
```
### Tools
`mllint` has a soft dependency on several Python tools that it uses for its analysis. While `mllint` will recommend that you place these tools in your project's development dependencies, these tools are listed as optional dependencies of `mllint` and can be installed along with `mllint` using:
```sh
pip install --upgrade mllint[tools]
```
### Docker
There are also `mllint` Docker containers available on [Docker Hub](https://hub.docker.com/r/bvobart/mllint) at `bvobart/mllint` for Python 3.6, 3.7, 3.8 and 3.9. These may particularly be helpful when running `mllint` in CI environments, such as Gitlab CI or Github Actions. See the Docker Hub for a full list of available tags that can be used.
The Docker containers require that you mount the folder with your project onto the container as a volume on `/app`. Here is an example of how to use this Docker container, assuming that your project is in the current folder. Replace `$(pwd)` with the full path to your project folder if it is somewhere else.
```sh
docker run -it --rm -v $(pwd):/app bvobart/mllint:latest
```
## Usage
`mllint` is designed to be used both on your personal computer as well as on CI systems. So, open a terminal in your project folder and run one of the following commands, or add it to your project's CI script.
To run `mllint` on the project in the current folder, simply run:
```sh
mllint
```
To run `mllint` on a project in another folder, simply run:
```sh
mllint path/to/my-ml-project
```
`mllint` will analyse your project and create a Markdown-formatted report of its analysis. By default, this will be pretty printed to your terminal. 
If you instead prefer to export the raw Markdown text to a file, which may be particularly useful when running on CI, the `--output` or `-o` flag and provide a filename. `mllint` does not overwrite the destination file if it already exists, unless `--force` or `-f` is used. For example:
```sh
mllint --output report.md
```
Using `-` (a dash) as the filename prints the raw Markdown directly to your terminal:
```sh
mllint -o -
```
In CI scripts, such raw markdown output (whether as a file or printed to the standard output) can be used to e.g. make comments on pull/merge requests or create Wiki pages on your repository.
See [docs/example-report.md](docs/example-report.md) for an example of a report that `mllint` generates, or explore those generated for the [example projects](https://github.com/bvobart/mllint-example-projects).
Of course, feel free to explore `mllint help` for more information about its commands and to discover additional flags that can be used.
### Linters, Categories and Rules
`mllint` analyses your project by evaluating several categories of linting rules. Each category, as well as each rule, has a 'slug', i.e., a lowercased piece of text with dashes or slashes for spaces, e.g., `code-quality/pylint/no-issues`. This slug identifies a rule and is often (if not always) displayed next to the category or rule that it references.
#### Command-line
To list all available (implemented) categories and linting rules, run:
```sh
mllint list all
```
To list all enabled linting rules, run (optionally providing the path to the project's folder):
```sh
mllint list enabled
```
By default, all of `mllint`'s rules are enabled. See [Configuration](#configuration) to learn how to selectively disable certain rules.
To learn more about a certain rule or category, use `mllint describe` along with the slug of the category or rule:
```sh
# Describe the Version Control category. This will also list the rules that it checks.
mllint describe version-control
# Use the exact slug of a rule to describe one rule,
# e.g., the rule on DVC usage in the Version Control category
mllint describe version-control/data/dvc
# Use a partial slug to describe all rules whose slug starts with this snippet, 
# e.g., all rules about version controlling data
mllint describe version-control/data
```
#### Online Documentation
Alternatively, visit the [Categories](https://bvobart.github.io/mllint/docs/categories/) and [Rules](https://bvobart.github.io/mllint/docs/rules/) pages on [`mllint`'s website](https://bvobart.github.io/mllint/) to view the latest online documentation of these rules.
### Custom linting rules
It is also possible to define your own custom linting rules by implementing a script or program that `mllint` will run while performing its analysis.

%package -n python3-mllint
Summary:	Software Quality Linter for Machine Learning projects
Provides:	python-mllint
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
BuildRequires:	python3-cffi
BuildRequires:	gcc
BuildRequires:	gdb
%description -n python3-mllint
## Installation
`mllint` is compiled for Linux, MacOS and Windows, both 64 and 32 bit x86 (MacOS 64-bit only), as well as 64-bit ARM on Linux and MacOS (Apple M1).
`mllint` is published to [PyPI](https://pypi.org/project/mllint/), so it can be installed globally or in your current environment using `pip`:
```sh
pip install --upgrade mllint
```
Alternatively, to add `mllint` to an existing project, if your project uses Poetry for its dependencies:
```sh
poetry add --dev mllint
```
Or if your project uses Pipenv:
```sh
pipenv install --dev mllint
```
### Tools
`mllint` has a soft dependency on several Python tools that it uses for its analysis. While `mllint` will recommend that you place these tools in your project's development dependencies, these tools are listed as optional dependencies of `mllint` and can be installed along with `mllint` using:
```sh
pip install --upgrade mllint[tools]
```
### Docker
There are also `mllint` Docker containers available on [Docker Hub](https://hub.docker.com/r/bvobart/mllint) at `bvobart/mllint` for Python 3.6, 3.7, 3.8 and 3.9. These may particularly be helpful when running `mllint` in CI environments, such as Gitlab CI or Github Actions. See the Docker Hub for a full list of available tags that can be used.
The Docker containers require that you mount the folder with your project onto the container as a volume on `/app`. Here is an example of how to use this Docker container, assuming that your project is in the current folder. Replace `$(pwd)` with the full path to your project folder if it is somewhere else.
```sh
docker run -it --rm -v $(pwd):/app bvobart/mllint:latest
```
## Usage
`mllint` is designed to be used both on your personal computer as well as on CI systems. So, open a terminal in your project folder and run one of the following commands, or add it to your project's CI script.
To run `mllint` on the project in the current folder, simply run:
```sh
mllint
```
To run `mllint` on a project in another folder, simply run:
```sh
mllint path/to/my-ml-project
```
`mllint` will analyse your project and create a Markdown-formatted report of its analysis. By default, this will be pretty printed to your terminal. 
If you instead prefer to export the raw Markdown text to a file, which may be particularly useful when running on CI, the `--output` or `-o` flag and provide a filename. `mllint` does not overwrite the destination file if it already exists, unless `--force` or `-f` is used. For example:
```sh
mllint --output report.md
```
Using `-` (a dash) as the filename prints the raw Markdown directly to your terminal:
```sh
mllint -o -
```
In CI scripts, such raw markdown output (whether as a file or printed to the standard output) can be used to e.g. make comments on pull/merge requests or create Wiki pages on your repository.
See [docs/example-report.md](docs/example-report.md) for an example of a report that `mllint` generates, or explore those generated for the [example projects](https://github.com/bvobart/mllint-example-projects).
Of course, feel free to explore `mllint help` for more information about its commands and to discover additional flags that can be used.
### Linters, Categories and Rules
`mllint` analyses your project by evaluating several categories of linting rules. Each category, as well as each rule, has a 'slug', i.e., a lowercased piece of text with dashes or slashes for spaces, e.g., `code-quality/pylint/no-issues`. This slug identifies a rule and is often (if not always) displayed next to the category or rule that it references.
#### Command-line
To list all available (implemented) categories and linting rules, run:
```sh
mllint list all
```
To list all enabled linting rules, run (optionally providing the path to the project's folder):
```sh
mllint list enabled
```
By default, all of `mllint`'s rules are enabled. See [Configuration](#configuration) to learn how to selectively disable certain rules.
To learn more about a certain rule or category, use `mllint describe` along with the slug of the category or rule:
```sh
# Describe the Version Control category. This will also list the rules that it checks.
mllint describe version-control
# Use the exact slug of a rule to describe one rule,
# e.g., the rule on DVC usage in the Version Control category
mllint describe version-control/data/dvc
# Use a partial slug to describe all rules whose slug starts with this snippet, 
# e.g., all rules about version controlling data
mllint describe version-control/data
```
#### Online Documentation
Alternatively, visit the [Categories](https://bvobart.github.io/mllint/docs/categories/) and [Rules](https://bvobart.github.io/mllint/docs/rules/) pages on [`mllint`'s website](https://bvobart.github.io/mllint/) to view the latest online documentation of these rules.
### Custom linting rules
It is also possible to define your own custom linting rules by implementing a script or program that `mllint` will run while performing its analysis.

%package help
Summary:	Development documents and examples for mllint
Provides:	python3-mllint-doc
%description help
## Installation
`mllint` is compiled for Linux, MacOS and Windows, both 64 and 32 bit x86 (MacOS 64-bit only), as well as 64-bit ARM on Linux and MacOS (Apple M1).
`mllint` is published to [PyPI](https://pypi.org/project/mllint/), so it can be installed globally or in your current environment using `pip`:
```sh
pip install --upgrade mllint
```
Alternatively, to add `mllint` to an existing project, if your project uses Poetry for its dependencies:
```sh
poetry add --dev mllint
```
Or if your project uses Pipenv:
```sh
pipenv install --dev mllint
```
### Tools
`mllint` has a soft dependency on several Python tools that it uses for its analysis. While `mllint` will recommend that you place these tools in your project's development dependencies, these tools are listed as optional dependencies of `mllint` and can be installed along with `mllint` using:
```sh
pip install --upgrade mllint[tools]
```
### Docker
There are also `mllint` Docker containers available on [Docker Hub](https://hub.docker.com/r/bvobart/mllint) at `bvobart/mllint` for Python 3.6, 3.7, 3.8 and 3.9. These may particularly be helpful when running `mllint` in CI environments, such as Gitlab CI or Github Actions. See the Docker Hub for a full list of available tags that can be used.
The Docker containers require that you mount the folder with your project onto the container as a volume on `/app`. Here is an example of how to use this Docker container, assuming that your project is in the current folder. Replace `$(pwd)` with the full path to your project folder if it is somewhere else.
```sh
docker run -it --rm -v $(pwd):/app bvobart/mllint:latest
```
## Usage
`mllint` is designed to be used both on your personal computer as well as on CI systems. So, open a terminal in your project folder and run one of the following commands, or add it to your project's CI script.
To run `mllint` on the project in the current folder, simply run:
```sh
mllint
```
To run `mllint` on a project in another folder, simply run:
```sh
mllint path/to/my-ml-project
```
`mllint` will analyse your project and create a Markdown-formatted report of its analysis. By default, this will be pretty printed to your terminal. 
If you instead prefer to export the raw Markdown text to a file, which may be particularly useful when running on CI, the `--output` or `-o` flag and provide a filename. `mllint` does not overwrite the destination file if it already exists, unless `--force` or `-f` is used. For example:
```sh
mllint --output report.md
```
Using `-` (a dash) as the filename prints the raw Markdown directly to your terminal:
```sh
mllint -o -
```
In CI scripts, such raw markdown output (whether as a file or printed to the standard output) can be used to e.g. make comments on pull/merge requests or create Wiki pages on your repository.
See [docs/example-report.md](docs/example-report.md) for an example of a report that `mllint` generates, or explore those generated for the [example projects](https://github.com/bvobart/mllint-example-projects).
Of course, feel free to explore `mllint help` for more information about its commands and to discover additional flags that can be used.
### Linters, Categories and Rules
`mllint` analyses your project by evaluating several categories of linting rules. Each category, as well as each rule, has a 'slug', i.e., a lowercased piece of text with dashes or slashes for spaces, e.g., `code-quality/pylint/no-issues`. This slug identifies a rule and is often (if not always) displayed next to the category or rule that it references.
#### Command-line
To list all available (implemented) categories and linting rules, run:
```sh
mllint list all
```
To list all enabled linting rules, run (optionally providing the path to the project's folder):
```sh
mllint list enabled
```
By default, all of `mllint`'s rules are enabled. See [Configuration](#configuration) to learn how to selectively disable certain rules.
To learn more about a certain rule or category, use `mllint describe` along with the slug of the category or rule:
```sh
# Describe the Version Control category. This will also list the rules that it checks.
mllint describe version-control
# Use the exact slug of a rule to describe one rule,
# e.g., the rule on DVC usage in the Version Control category
mllint describe version-control/data/dvc
# Use a partial slug to describe all rules whose slug starts with this snippet, 
# e.g., all rules about version controlling data
mllint describe version-control/data
```
#### Online Documentation
Alternatively, visit the [Categories](https://bvobart.github.io/mllint/docs/categories/) and [Rules](https://bvobart.github.io/mllint/docs/rules/) pages on [`mllint`'s website](https://bvobart.github.io/mllint/) to view the latest online documentation of these rules.
### Custom linting rules
It is also possible to define your own custom linting rules by implementing a script or program that `mllint` will run while performing its analysis.

%prep
%autosetup -n mllint-0.12.2

%build
%py3_build

%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
	find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
	find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
	find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
	find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
	find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .

%files -n python3-mllint -f filelist.lst
%dir %{python3_sitearch}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Tue Apr 11 2023 Python_Bot <Python_Bot@openeuler.org> - 0.12.2-1
- Package Spec generated