Feature Request: New Project generation

[AstraLuma]

I've lost track myself. Can you add a command to generate template pyproject.toml/setup.{cfg,py} files?

(I include setup.py because pips that don't support setup.py-less packages are still super common)

[AstraLuma]

Just, general purpose, low-opinion stuff? I'm thinking it would generate three files:

• A setup.py that just contains bootstrap code (For backwards compatibility and editable installs)
• A setup.cfg file with metadata and comments (Maybe based on https://github.com/pypa/sampleproject ? Also probably with some README detection)
• A pyproject.toml that says to use setuptools

If you're feeling particularly opinionated, maybe include hooks for setuptools-scm?

[AstraLuma]

Yeah, you probably want something like cookie cutter for more complete project generation.

[duckinator]

Also, to clarify, it would plop it in the CWD. The purpose of providing MODULE_NAME is purely to fill in a few values.

[AstraLuma]

I figured you'd just drop in the metadata from the sample and let the developer fix it up. It doesn't have to be right, just has to be enough to get rolling.

I mean, I've been doing python for over a decade and I still don't remember all the metadata fields

[AstraLuma]

Can you include links to docs in the setup.cfg? In particular, the license and classifier lists.

I'm also not seeing any "long description" options.

[duckinator]

Yup, I can definitely do that! Will need to find them at some point (not hard; just don't have the time atm). I've also been considering making a small website for bork which includes a page with details about common setup.cfg setups.

Also, edited my last comment to include long_description, since I'll likely be copy/pasting that for the basis of this feature whenever it's implemented.

[AstraLuma]

long_description is usually file: README.* these days (autodetect readme, and include the appropriate MIME if need be?)

[duckinator]

So, as an update: I'm still okay with this, but I think a lot of refactoring needs to happen first. The codebase has gotten too unwieldy for me to feel comfortable adding entire new commands right now.

[duckinator]

Everything can be done in pyproject.toml now, even when using setuptools. So this means only a single file needs to be created.

pyproject.toml docs: https://packaging.python.org/en/latest/specifications/declaring-project-metadata/

setuptools-specific docs: https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

editable mode, no setup.py needed: https://setuptools.pypa.io/en/latest/userguide/development_mode.html (pip install -e .)

[duckinator]

Potential starting point for the generated `pyproject.toml`

# This file was originally generated by Bork.
# Please go through the file and make sure it's
# configured appropriately for your project. <3
#
# In particular, be sure to replace:
# - PACKAGE with your package name (it is recommended to have it be all-lowercase)
# - AUTHORNAME with the name of the first author
# - AUTHOREMAIL with the email for the first author
# - DESCRIPTION with a short description
# - LICENSE with your license of choice

[build-system]
# Specify the required build system.
requires = ["setuptools >= 61", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "PACKAGE"

# Specify that the package version is defined dynamically.
dynamic = ["version"]

# List of authors of the project.
authors = [
    {name = "AUTHORNAME", email = "AUTHOREMAIL"},
]

# A brief description of the project.
description = "DESCRIPTION"

# Update this if your README file is different (e.g. README.rst).
readme = "README.md"

# Update this to specify the license you're using!
license = {text = "LICENSE"}

# None of these are *required*.
# See https://pypi.org/classifiers/ for a complete list and
# instructions on how to prevent uploading to PyPi using classifiers.
classifiers = [
    "Programming Language :: Python :: 3",
]

# The runtime dependencies for your project.
dependencies = [
]

# The minimum Python version you support.
# You can determine which Python versions are supported at:
# https://devguide.python.org/versions/
requires-python = ">= 3.8"

[project.urls]
# The URL to your repository. This might be on GitHub or GitLab, for example.
#repository = "https://..."
# The URL to your documentation.
#documentation = "https://..."

[project.optional-dependencies]
# While your optional-dependencies can be named (basically) whatever you want,
# Bork went ahead and set up some common ones for you.
# You don't have to use them if you don't want to. <3

# These can be installed via `pip install .[lint]`
lint = [
    "pylint",
]

# These can be installed via `pip install .[test]`
test = [
    "pytest",
]

# These can be installed via `pip install .[dev]`
dev = [
    ".[lint]",
    ".[test]",
    "bork",
]

[project.scripts]
# These are the command-line scripts for your project.
# If you want `some-tool` to call `main()` from `some_tool.cli`, you'd do this:
#    some-tool = "some_tool.cli:main"

[tools.setuptools]
# If auto-detection of project names doesn't work,
# or you just don't want to use it for some reason,
# set tools.setuptools.packages below.
#packages = ["PACKAGE"]

[tool.setuptools.dynamic]
# This assumes your project exports `PACKAGE.__version__`.
# If you define it elsewhere, update this!
version = {attr = "PACKAGE.__version__"}

[tool.bork.zipapp]
# If true, generate a Zipapp. Otherwise, don't.
enabled = false

# The entrypoint for the zipapp. This is usually the same
# as one of the values in [project.scripts], but sometimes
# you need zipapp-specific workarounds.
main = "some_module.cli:main"

[tool.bork.release]
# If true, release to PyPi.
pypi = false

# If true, release to GitHub.
github = false

# The GitHub repository to upload releases to.
#github_repository = "some-user/some-repo"

# If true, remove "-<version>" from the zipapp name when
# uploading to e.g. GitHub.
strip_zipapp_version = true

[tool.bork.aliases]
#lint = [
#    "pylint PACKAGE",
#]
# Runs all tests.
test = "pytest --verbose"