# Specfile generator

## User Stories

As a Fedora packager of a library
I want to create a quality RPM package (conforming to the guidelines)
in order to submit it to Fedora.

As a devops person
I want to quickly create a working RPM package of a Python library
in order to install it on my machine(s).

As a maintainer of a library
I want to create packages with working `%check`
in order to test projects that depend on my library.

As a Fedora packager
I want to install the tool with DNF
in order to start using it.

As a Python developer
I want to install the tool with pip
in order to start using it.

As a project maintainer
I want to specify non-Python dependencies
in order to build working RPMs.

As a packager
I want to easily specify what I am packaging (e.g. Python package name, version).

As a packager
I want to package the latest version by default, using the same logic as pip (e.g. no yanked versions, only use pre-release if explicitly told to or if there are only pre-releases, etc.).

As a packager
I want to be able to explicitly configure some choices (e.g. force a certain decision with a command line argument).

As a devops person
I don't want to be bothered with questions. The tool must work in fully automated mode that does not need any input other than package name.

As a packager
I want to be able to package pre-release versions of the software (e.g. devs, alphas, betas) as well as regular versions and post-releases.

As an upstream developer
I want to be able to test my package on Fedora-RPM-based CI (e.g. via Copr, Packit, etc.) without a need to store a spec file in VCS or be bothered with ~~spec~~ Fedora-specific files at all.

- XXX ksurma: thinking as an upstream dev - I don't want to be bothered by Fedora-nuances too much (probably packing other distributions as well), I certainly don't want to edit another config with the same data I already have - not sure if this is a material for a full user story
- pviktori: +1; all info should be in Python-style metadata (pyproject.toml, tox.ini, etc.)

As a —
I want to —
in order to —

### Extras (not in MVP)

As a "proper" Fedora packager
I want to automatically include all extras that are installable in Fedora (with manual includes/excludes).

As a Copr packager
I want to automatically include all extras that are installable in my Copr, (with manual includes/excludes).

As a Fedora packager
I want to easily extend the included extras when a dependency is added to Fedora.

As a Fedora packager
I want to easily reduce the included extras when a dependency is retired from Fedora, preserving the upgrade path.

As a Fedora packager
I want to easily update the package when a new version comes out
in order to continue maintaining it. That includes preserving my manual changes whenever possible.

As a corporate developer
I want to be able to use custom (e.g. internal) package index instead of pypi.org.

## Requirements

* Security: it should be (reasonably) safe to use the tool on random code from the internet

* Standards: all choices the tool makes should (eventually) be standardized and shared across all relevant tools.
(For example: choosing how to run tests -- tox, pytest, etc.)

* Explicit over heuristics: if the tool does not have a standardized way to make a decision, it should avoid the temptation to guess, and should guide the user to make an explicit choice instead, falling back to well documented default. Relying on heuristics everywhere will make tool unmaintainable in the long run.

* Complete: It should support everything mentioned in the Packaging Guidelines (when appropriate).

## Non-goals (in the MVP)

* Support for applications
* Application naming
* Executables (/usr/bin/\*) -- XXX mhroncok: that is fairly easy and could be supported from the start

* Extras

* -doc subpackages

* Updating an existing package

* `sed`ing / patching out unwanted dependencies

## Tool brainstorming

* "Guesser" - asks PyPI, downloads stuff, builds stuff?; generates a config (like `.rust2rpm.conf`)
*- ksurma: in what cases would we like to build stuff?*
- mhroncok: some things can only be recognized from a wheel (or similar artifacts) if we don't want to rely on heuristics, e.g. "does this project install extension modules?"
* Inputs:
* package name -> download from PyPI, build?
* file/URL -> build
* "Generator" - deterministically uses the config to make a spec file
* (later, maybe never) "Updater" - like guesser, but update an existing config