PyScaffold is a project generator for bootstrapping high quality Python packages

PyScaffold

Last update: Jan 3, 2023

Overview

PyScaffold is a project generator for bootstrapping high quality Python packages, ready to be shared on PyPI and installable via pip. It is easy to use and encourages the adoption of the best tools and practices of the Python ecosystem, helping you and your team to stay sane, happy and productive. The best part? It is stable and has been used by thousands of developers for over half a decade!

Checkout out this demo project, which was set up using PyScaffold and if you are still not convinced yet, also have a look at these reasons to use PyScaffold.

NOTE - This document refers to the latest version of PyScaffold (v4). Please refer to v3.3 for the previous stable version.

Quickstart

Just pick your favourite installation method:

## Good old pip
# (make sure it is up-to-date: pip install -U pip setuptools)
pip install pyscaffold

## Conda for the datascience fans
conda install -c conda-forge pyscaffold

## Or even pipx for the virtualenv aficionados
pipx install pyscaffold

If you want to install all PyScaffold's extensions you can even:

pip install pyscaffold[all]

(More details of each method are available in the installation docs)

After the installation, a new putup command will be available and you can just type:

putup my_project

This will create a new folder called my_project containing a perfect project template with everything you need for some serious coding.

After cd-ing into your new project and creating (or activating) an isolated development environment (with virtualenv, conda or your preferred tool), you can do the usual editable install:

pip install -e .

… all set and ready to go!

We also recommend using tox, so you can take advantage of the automation tasks we have setup for you, like:

tox -e build  # to build your package distribution
tox -e publish  # to test your project uploads correctly in test.pypi.org
tox -e publish -- --repository pypi  # to release your package to PyPI
tox -av  # to list all the tasks available

The following figure demonstrates the usage of putup with the new experimental interactive mode for setting up a simple project. It uses the --cirrus flag to add CI support (via Cirrus CI), and tox to run automated project tasks like building a package file for distribution (or publishing).

Creating a simple package with PyScaffold

Type putup -h to learn about more configuration options. PyScaffold assumes that you have Git installed and set up on your PC, meaning at least your name and email are configured.

The project template provides you with following features:

Configuration & Packaging

All configuration can be done in setup.cfg like changing the description, URL, classifiers, installation requirements and so on as defined by setuptools. That means in most cases it is not necessary to tamper with setup.py.

In order to build a source or wheel distribution, just run tox -e build (if you don't use tox, you can also install build and run python -m build).

Package and Files Data

Additional data, e.g. images and text files, that reside within your package and are tracked by Git will automatically be included if include_package_data = True in setup.cfg. It is not necessary to have a MANIFEST.in file for this to work.

Note that the include_package_data option in setup.cfg is only guaranteed to be read when creating a wheels distribution. Other distribution methods might behave unexpectedly (e.g. always including data files even when include_package_data = False). Therefore, the best option if you want to have data files in your repository but not as part of the pip installable package is to add them somewhere outside the src directory (e.g. a files directory in the root of the project, or inside tests if you use them for checks). Additionally you can exclude them explicitly via the [options.packages.find] exclude option in setup.cfg.

Versioning and Git Integration

Your project is an already initialised Git repository and uses the information of tags to infer the version of your project with the help of setuptools_scm. To use this feature, you need to tag with the format MAJOR.MINOR[.PATCH] , e.g. 0.0.1 or 0.1. .. Run python -m setuptools_scm to retrieve the current PEP440-compliant version. This version will be used when building a package and is also accessible through my_project.__version__.

Unleash the power of Git by using its pre-commit hooks. This feature is available through the --pre-commit flag. After your project's scaffold was generated, make sure pre-commit is installed, e.g. pip install pre-commit, then just run pre-commit install.

A default .gitignore file is also provided; it is well adjusted for Python projects and the most common tools.

Sphinx Documentation

PyScaffold will prepare a docs directory with all you need to start writing your documentation. Start editing the file docs/index.rst to extend the documentation. The documentation also works with Read the Docs.

The Numpy and Google style docstrings are activated by default.

If you have tox in your system, simply run tox -e docs or tox -e doctests to compile the docs or run the doctests.

Alternatively, if you have make and Sphinx installed in your computer, build the documentation with make -C docs html and run doctests with make -C docs doctest. Just make sure Sphinx 1.3 or above is installed.

Automation, Tests & Coverage

PyScaffold relies on pytest to run all automated tests defined in the subfolder tests. Some sane default flags for pytest are already defined in the [tool:pytest] section of setup.cfg. The pytest plugin pytest-cov is used to automatically generate a coverage report. It is also possible to provide additional parameters and flags on the commandline, e.g., type:

pytest -h

to show the help of pytest (requires pytest to be installed in your system or virtualenv).

Projects generated with PyScaffold by default support running tests via tox, a virtualenv management and test tool, which is very handy. If you run:

tox

in the root of your project, tox will download its dependencies, build the package, install it in a virtualenv and run the tests using pytest, so you are sure everything is properly tested.

JUnit and Coverage HTML/XML

For usage with a continuous integration software JUnit and Coverage XML output can be activated in setup.cfg. Use the flag --cirrus to generate templates of the Cirrus CI configuration file .cirrus.yml which even features the coverage and stats system Coveralls.

Management of Requirements & Licenses

Installation requirements of your project can be defined inside setup.cfg, e.g. install_requires = numpy; scipy. To avoid package dependency problems it is common to not pin installation requirements to any specific version, although minimum versions, e.g. sphinx>=1.3, and/or maximum versions, e.g. pandas<0.12, are used frequently in accordance with semantic versioning.

All licenses from choosealicense.com can be easily selected with the help of the --license flag.

Extensions

PyScaffold comes with several extensions:

If you want a project setup for a Data Science task, just use --dsproject after having installed pyscaffoldext-dsproject.
Have a README.md based on Markdown instead of README.rst by using --markdown after having installed pyscaffoldext-markdown.
Create a Django project with the flag --django which is equivalent to django-admin startproject my_project enhanced by PyScaffold's features (requires pyscaffoldext-django).
… and many more like --gitlab to create the necessary files for GitLab, --travis for Travis CI (see pyscaffoldext-travis), or --cookiecutter for Cookiecutter integration (see pyscaffoldext-cookiecutter).

Find more extensions within the PyScaffold organisation and consider contributing your own, it is very easy! You can quickly generate a template for your extension with the --custom-extension option after having installed pyscaffoldext-custom-extension.

All extensions can easily be installed with pip install pyscaffoldext-NAME.

Easy Updating

Keep your project's scaffold up-to-date by applying putup --update my_project when a new version of PyScaffold was released. An update will only overwrite files that are not often altered by users like setup.py. To update all files use --update --force. An existing project that was not setup with PyScaffold can be converted with putup --force existing_project. The force option is completely safe to use since the git repository of the existing project is not touched!

Comments

$subprocess.run('git --version') returns '& was unexpected at this time.\n' and false error of git not installed$

subprocess.run('git --version') returns '& was unexpected at this time.\n' and false error of git not installed

Description of your problem

running putup returns ... ERROR: Make sure git is installed and working.

GIt is installed and working both in powershell and Git Bash. Tested using git --version PATH variables are set and checked.

I made a study of the issue and proved that git actually runs but that the subprocess.run method returns an error snf stdout returns : '& was unexpected at this time.'

Please provide a minimal, self-contained, and reproducible example. The following snippet is provided from the method run in 'ShellCommand class'

#        return subprocess.run(command, **opts)
        # ^ `check_output` does not seem to support terminal editors

    def __call__(self, *args, **kwargs) -> Iterator[str]:
        """Execute the command, returning an iterator for the resulting text output"""
        completed = self.run(*args, **kwargs)
        try:
            completed.check_returncode()
        except subprocess.CalledProcessError as ex:
            msg = "\n".join(e or "" for e in (completed.stdout, completed.stderr))
            raise ShellCommandException(msg) from ex

Debugging, I find that the returned completed object is returned as follows:

CompletedProcess(args='git --version', returncode=1, stdout='& was unexpected at this time.\n')*

Please provide the full traceback.

# Traceback (most recent call last):
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\exceptions.py", line 33, in func_wrapper
    func(*args, **kwargs)
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\cli.py", line 263, in run
    main(args or sys.argv[1:])
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\cli.py", line 256, in main
    opts["command"](opts)
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\cli.py", line 225, in run_scaffold
    api.create_project(opts)
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\api.py", line 156, in create_project
    return reduce(actions.invoke, pipeline, ({}, opts))
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\actions.py", line 98, in invoke
    return action(*struct_and_opts)
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\actions.py", line 221, in get_default_options
    info.check_git()
  File "C:\Users\kevin\miniconda3\lib\site-packages\pyscaffold\info.py", line 126, in check_git
    raise GitNotInstalled
pyscaffold.exceptions.GitNotInstalled: Make sure git is installed and working.
ERROR: Make sure git is installed and working.

Please provide any additional information below. Please find attached my study code that was used for the debug below

shellstudy.zip

Versions and main components

PyScaffold Version: PyScaffold 4.1.1
Python Version: Python 3.9.1 (default, Dec 11 2020, 09:29:25) [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
Operating system: ms Windows Version 10.0.19043
How did you install PyScaffold: (conda/pip) Installed using pip

bug

opened by ksteptoe 44

Proposal: a Template for custom extensions

Hello guys,

yesterday I was thinking about the custom extension I wrote for my company and how to frame my use case. I thought back about your documentation on how to create a custom extension and while it's not so difficult, I realized that all that knowledge could be easily transfered into a pyscaffold extension. So basically a template to create a project that is ready to be filled with some logic to customize the extension. This process now is not super complicated but you need to figure out the namespace thing and you need to find what exactly you need to extend and how. A class could be provided, already in the right namespace and with the proper structure, maybe implementing already some very common pattern. One could be simply picking up files from a "resource" directory and copy them in the newly created project, so that the most common use case (adding new files and templates) requires the user to simply move files into the extension/resource folder.

Does it make sense?
enhancement

opened by chobeat 36
Support for cookiecutter is under-documented
First, pyscaffold is great! Thanks!

Second, cookiecutter support is a great addition. Without it, there's no way to do organization-, project-, or framework-specific boilerplate reduction.

As of right now, though, the putup --with-cookiecutter experience is a little bit confusing. The extent of the putup --help is:

PyScaffold is a tool for easily putting up the scaffold of a Python project. positional arguments: PROJECT project name optional arguments: ... --with-cookiecutter TEMPLATE additionally apply a cookiecutter template

The narrative documentation in the README.md is:

Django & Cookiecutter ===================== Create a `Django project <https://www.djangoproject.com/>`_ with the flag ``--with-django`` which is equivalent to ``django-admin.py startproject my_project`` enhanced by PyScaffold's features. With the help of `Cookiecutter <https://cookiecutter.readthedocs.org/>`_ it is possible to customize your project setup. Just use the flag ``--with-cookiecutter TEMPLATE`` to use a cookiecutter template which will be refined by PyScaffold afterwards.

For the naive user, there is (A) a tendency to want to believe that the --with-cookiecutter option can be applied to any existing cookiecutter template when, in fact, (B) the template needs to be designed to work with pyscaffold. Unintended consequences are par for the course.

To combat #A, there should probably be a warning in both the README and the --help.

To combat #B, there should be some narrative documentation that explains how to build a cookiecutter template for pyscaffold.
enhancement
opened by brianthelion 28
Improve Versioning and Git Integration doc section
Describe your use-case

Improve Versioning and Git Integration doc section. For an example I have no idea how to remove commit id and other values from the build version which looks like

python setup.py --version 2.0.0.post0.dev1+g59e85d7

instead just

2.0.0

Describe the solution you would like to see for your use-case

Expand documentation section or create examples.
opened by raszkiewicz 24
Add pyproject.toml by default
It seems that pyproject.toml is here to stay. Some tools like black already use it to store its configurations. Thus every new project should have one with the content:

[build-system] requires = ["wheel", "setuptools", "setuptools-scm"] build-backend = "setuptools.build_meta"
enhancement
opened by FlorianWilhelm 20
Pyscaffold pytorch extension
Describe your use-case

Hey, I was quite impressed by the --dsproject extension, and I'm using it heavily for a bunch of projects. I would like to contribute and create a pytorch specific extension which basically combines pyscaffoldext-dsproject and a commonly used pytorch template such as https://github.com/L1aoXingyu/Deep-Learning-Project-Template.

I've currently started making it on pyscaffoldext-custom-extension along with pyscaffoldext-dsproject, but I have a couple of questions :-

If I make it, is it possible to get someone to review it?

How do I test it locally?

Are --dsproject and --custom-extension incompatible? I see some missing files with it.

Should I rather clone --dsproject and start from there?

Describe the solution you would like to see for your use-case

An extension that is adapted just for PyTorch.
enhancement
opened by prassanna-ravishankar 16
include_package_data = False is ignored
Description of your problem

I am developing a Python package, whose directory structure has been laid out with Pyscaffold. The repository contains some directory and files that I do not want to include in the actual package (e.g. the Dockerfile for the container, the folder for CI/CD etc. etc.) but that I do need under version control.

I set include_package_data = False but all the files under version control are actually included in the package when I run

python setup.py sdist

I am sure it's just a misunderstanding on my side, but how can I let setuptools/pyscaffold only include certain folders and not others? I have also tried to set

[options.exclude_package_data]

= *

but regardless all the folders in the repository end up in the sdist package archive

Please provide a minimal, self-contained, and reproducible example.

python setup.py develop

Please provide the full traceback.

[The error output here]

Please provide any additional information below.

Versions and main components

PyScaffold Version: 3.2.3

Python Version: 3.7

Operating system: MacOS

How did you install PyScaffold: pipx

bug
opened by lucacerone 16
How to control updated files in an extension?

Hello guys.

To simplify my issue, what I need is to be able to update an existing template by updating exclusively the files related to my extension. For instance, I don't want to overwrite the setup.py because I have my entry points there. So I would like to just overwrite the files specified by my extension when I update but have a full template together with my extension when I create the project the first time.

How to achieve that?

Thank you.

opened by chobeat 16
Add an interactive feature to putup

Using putup many people are often not aware of the many options it has. This results in projects that lack features like pre-commit and tox that people would actually choose if they knew about. One way to resolve this is to add an --interactive or -i feature to putup that asks the user about each option with sane defaults. Cookiecutter is doing something similar in its input mode.
needs discussion

opened by FlorianWilhelm 16

Pyscaffold breaks with setuptools version 39

I get an error like

      File "/tmp/pip-build-gwh071/damsat/.eggs/PyScaffold-2.5.8-py2.7.egg/pyscaffold/utils.py", line 239, in check_setuptools_version
        "Your setuptools version is too old (<12). "
    RuntimeError: Your setuptools version is too old (<12). Use `pip install -U setuptools` to upgrade.
    If you have the deprecated `distribute` package installed remove it or update to version 0.7.3.

The reason is that SetuptoolsVersion was removed. See https://github.com/pypa/setuptools/blob/master/CHANGES.rst#v3900

bug

opened by cpaulik 16

Update error message as this failure can be caused by distribute too

An ImportError can be raised here when the python package distribute is too old too, not just setuptools:

    Installed /tmp/pip-build-NuXIK3/stratosphere-client/setuptools_scm-1.8.0-py2.7.egg
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-NuXIK3/stratosphere-client/setup.py", line 24, in <module>
        setup_package()
      File "/tmp/pip-build-NuXIK3/stratosphere-client/setup.py", line 20, in setup_package
        use_pyscaffold=True)
      File "/usr/lib/python2.7/distutils/core.py", line 112, in setup
        _setup_distribution = dist = klass(attrs)
      File "/home/vagrant/.virtualenvs/ansible/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/setuptools/dist.py", line 225, in __init__
        _Distribution.__init__(self,attrs)
      File "/usr/lib/python2.7/distutils/dist.py", line 287, in __init__
        self.finalize_options()
      File "/home/vagrant/.virtualenvs/ansible/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/setuptools/dist.py", line 258, in finalize_options
        ep.load()(self, ep.name, value)
      File "/tmp/pip-build-NuXIK3/stratosphere-client/PyScaffold-2.5b2-py2.7.egg/pyscaffold/integration.py", line 104, in pyscaffold_keyword
        check_setuptools_version()
      File "/tmp/pip-build-NuXIK3/stratosphere-client/PyScaffold-2.5b2-py2.7.egg/pyscaffold/utils.py", line 210, in check_setuptools_version
        "ERROR: Your setuptools version is too old (<12).\n"
    RuntimeError: ERROR: Your setuptools version is too old (<12).
    Use `pip install -U setuptools` to upgrade.

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-NuXIK3/stratosphere-client
(ansible)vagrant@precise64:~/airflow:master  X $ python
Python 2.7.3 (default, Jun 22 2015, 19:33:41)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import parse_version, SetuptoolsVersion
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name SetuptoolsVersion
>>> quit()
(ansible)vagrant@precise64:~/airflow:master  X $ pip install -U distribute
/home/vagrant/.virtualenvs/ansible/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Collecting distribute
  Using cached distribute-0.7.3.zip
Requirement already up-to-date: setuptools>=0.7 in /home/vagrant/.virtualenvs/ansible/lib/python2.7/site-packages (from distribute)
Installing collected packages: distribute
  Found existing installation: distribute 0.6.24
    Uninstalling distribute-0.6.24:
      Successfully uninstalled distribute-0.6.24
  Running setup.py install for distribute
Successfully installed distribute-0.7.3
(ansible)vagrant@precise64:~/airflow:master  X $ python
Python 2.7.3 (default, Jun 22 2015, 19:33:41)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import parse_version, SetuptoolsVersion
>>> quit()
(ansible)vagrant@precise64:~/airflow:master  X $

enhancement

opened by kopf 16

Tests don't run with the correct Python version in GitHub Actions
Description of your problem

My expectation was that the "Run tests" step of the test job were run with the Python version set up in the setup-python action of the same job. So when ${{ matrix.python }} is 3.7, I would expect that the tests on all three operating systems would run on Python 3.7.

Instead, I see the tests running on different versions depending on the operating system in ${{ matrix.platform }}:

ubuntu-latest: Python 3.10

macos-latest: Python 3.11

windows-latest: Python 3.9

Please provide any additional information below.

You can see this in action in this action run of my project humble-explorer, that I bootstrapped last month with PyScaffold.

In the test run for Ubuntu pytest starts with platform linux -- Python 3.10.6, pytest-7.2.0, pluggy-1.0.0 -- /home/runner/work/humble-explorer/humble-explorer/.tox/default/bin/python.

In the test run for macOS pytest starts with platform darwin -- Python 3.11.0, pytest-7.2.0, pluggy-1.0.0 -- /Users/runner/work/humble-explorer/humble-explorer/.tox/default/bin/python.

In the test run for Windows pytest starts with platform win32 -- Python 3.9.13, pytest-7.2.0, pluggy-1.0.0 -- D:\a\humble-explorer\humble-explorer\.tox\default\Scripts\python.EXE.

I just noticed this because my project used some version-specific Python features and didn't fail in the right test runs. The test runs seem to use the default system-wide installed versions of Python on these GitHub action runners instead of the ones set up by the setup-python action.

Possible solution

I solved this in my case by adding id: setup-python to the setup-python step so I could refer to the path of the installed Python interpreter, and then adding the parameter --python '${{ steps.setup-python.outputs.python-path }}' after pipx run when running the tests, to explicitly set the Python binary to use. See this commit for an example.

This seems to do the job: with this change the action runs the tests on Python 3.7 when ${{ matrix.python }} is 3.7, on all operating systems. I checked this too for 3.8, 3.9, 3.10 and 3.11.

If you agree with this solution, I can create a PR to fix this in PyScaffold's GitHub CI template.

Versions and main components

PyScaffold Version: 4.3.1

Python Version: 3.10.6

Operating system: Ubuntu 22.04.1 LTS

How did you install PyScaffold: pip
opened by koenvervloesem 0
GitHub actions seems to still be using sdist - should this be adjusted to bdist_wheel?
Description of your problem

Please provide a minimal, self-contained, and reproducible example.

The following command would probably work.

putup --github-actions

See this GitHub actions runner.

I got a "File too large" error when trying to publish to PyPI because files other than what's in src are added to the distribution. I came across https://github.com/pyscaffold/pyscaffold/issues/404 which mentioned the use of sdist vs. bdist_wheel, where the latter is recommended. Checking the GitHub actions log, I'm seeing that sdist is being used during:

pipx run --spec tox==3.27.1 tox -e clean,build

which calls:

python -m build

where build is a Python package and produces the message:

... Getting build dependencies for sdist... ...

Please provide the full traceback using the --very-verbose flag.

# [The error output here]

Please provide any additional information below. I'd like for only src files to be added to the distribution by default.

Versions and main components

PyScaffold Version: 4.2.3.post1.dev10+g7a0f254

Python Version:

Operating system: Windows

How did you install PyScaffold: (conda/pip) I don't remember, but can check if it's pertinent
opened by sgbaird 2
tox stopped working on GitHub actions due to tox major version update
Description of your problem

My GitHub actions CI suddenly started giving the following error https://github.com/sparks-baird/self-driving-lab-demo/actions/runs/3666140871/jobs/6197685437#step:5:18:

tox -e py --installpkg dist/*.whl

ROOT: HandledError| .pkg_external is already defined as a virtualenv-cmd-builder, cannot be virtualenv-pep-517 too Error: Process completed with exit code 254.

At one point, it was also installing Python 3.11 even though "3.10" was specified. Seemed to be fixed by moving the with argument to a new line

Mentioned by someone else here https://github.com/beeware/briefcase/pull/994.

I haven't repro'd this from scratch with the latest build yet.

Please provide any additional information below. Scheduled test on 2022-12-07T14:06:55.6352295Z that ran successfully: https://github.com/sparks-baird/self-driving-lab-demo/actions/runs/3639637826 Scheduled test on 2022-12-07T22:07:25.2284089Z that failed: https://github.com/sparks-baird/self-driving-lab-demo/actions/runs/3643224057 Note that it's the same commit (i.e. no difference between the repos)

Versions and main components

This project has been set up using [PyScaffold] 4.2.3.post1.dev10+g7a0f254 and the [dsproject extension] 0.7.2.post1.dev3+g948a662.
opened by sgbaird 5
[Feature Request] Scaffold component for VS Code container development integration

Apologies if this already exists or was discussed somewhere else, but I couldn't find.

Describe your use-case

It'd be really great if there was a scaffold component for VS Code container development integration similar to: https://github.com/avsolatorio/pyscaffoldext-dsproject-vscode

Describe the solution you would like to see for your use-case

Automatically creating a .devcontainer directory with 3 files: Dockerfile, devcontainer.json, and requirements.txt. Details: https://code.visualstudio.com/docs/devcontainers/containers

opened by austinmw 0

Tests don't run after migrating to pyscaffold

Description of your problem

After migrating to pyscaffold, I get some errors trying to run tox.

Please provide a minimal, self-contained, and reproducible example.

Checkout https://codeberg.org/ofosos/rotoscope version f80378ef7dbec85dd86b4427ca9e2eee5af60779

# tox

Please provide the full traceback using the --very-verbose flag.

/Users/mark/PycharmProjects/rotoscope/venv/bin/Python /Applications/PyCharm.app/Contents/plugins/python/helpers/pycharm/_jb_tox_runner.py
Testing started at 23:10 ...
.package recreate: /Users/mark/PycharmProjects/rotoscope/.tox/.package
.package installdeps: setuptools>=46.1.0, setuptools_scm[toml]>=5, wheel
WARNING: Discarding $PYTHONPATH from environment, to override specify PYTHONPATH in 'passenv' in your configuration.
/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/version.py:67: UserWarning: tag 'draft1' no version found
  warnings.warn(f"tag {tag!r} no version found")
Traceback (most recent call last):
  File "venv/lib/python3.8/site-packages/tox/helper/build_requires.py", line 16, in <module>
    for_build_requires = backend.get_requires_for_build_sdist(None)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/build_meta.py", line 181, in get_requires_for_build_sdist
    return self._get_build_requires(config_settings, requirements=[])
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/build_meta.py", line 159, in _get_build_requires
    self.run_setup()
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/build_meta.py", line 174, in run_setup
    exec(compile(code, __file__, 'exec'), locals())
  File "setup.py", line 13, in <module>
    setup(use_scm_version={"version_scheme": "no-guess-dev"})
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/__init__.py", line 87, in setup
    return distutils.core.setup(**attrs)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/_distutils/core.py", line 109, in setup
    _setup_distribution = dist = klass(attrs)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/dist.py", line 477, in __init__
    _Distribution.__init__(
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 293, in __init__
    self.finalize_options()
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/dist.py", line 901, in finalize_options
    ep(self)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools/dist.py", line 922, in _finalize_setup_keywords
    ep.load()(self, ep.name, value)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/integration.py", line 75, in version_keyword
    _assign_version(dist, config)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/integration.py", line 48, in _assign_version
    maybe_version = _get_version(config)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/__init__.py", line 151, in _get_version
    parsed_version = _do_parse(config)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/__init__.py", line 98, in _do_parse
    version = _version_from_entrypoints(config) or _version_from_entrypoints(
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/_entrypoints.py", line 37, in _version_from_entrypoints
    version: Optional[ScmVersion] = _call_entrypoint_fn(root, config, ep.load())
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/_entrypoints.py", line 13, in _call_entrypoint_fn
    return fn(root, config=config)
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/git.py", line 146, in parse
    return _git_parse_inner(
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/git.py", line 181, in _git_parse_inner
    return meta(
  File "/Users/mark/PycharmProjects/rotoscope/.tox/.package/lib/python3.8/site-packages/setuptools_scm/version.py", line 195, in meta
    assert parsed_version is not None, "Can't parse version %s" % tag
AssertionError: Can't parse version draft1
ERROR: invocation failed (exit code 1), logfile: /Users/mark/PycharmProjects/rotoscope/.tox/.package/log/.package-2.log
================================== log start ===================================


An error occurred while building the project, please ensure you have the most updated version of setuptools, setuptools_scm and wheel with:
   pip install -U setuptools setuptools_scm wheel



=================================== log end ====================================
ERROR: FAIL could not package project - v = InvocationError("/Users/mark/PycharmProjects/rotoscope/.tox/.package/bin/python venv/lib/python3.8/site-packages/tox/helper/build_requires.py setuptools.build_meta '' ''", 1)

Process finished with exit code 2

Empty suite

Please provide any additional information below.

This commit of mine fixes the problem: https://codeberg.org/ofosos/rotoscope/commit/239d3a0cdb0e34bb1fb5c83878db7669e2f83905

Versions and main components

PyScaffold Version: 4.2.2
Python Version: 3.8
Operating system: Mac OS 12.4 / Apple Silicon
How did you install PyScaffold: pip

documentation

opened by ofosos 14

Releases(v4.3.1)

v4.3.1(Sep 20, 2022)
What's Changed

Modify tox.ini template to allow passing the TWINE_REPOSITORY_URL environment variable, https://github.com/pyscaffold/pyscaffold/pull/666

New Contributors

@mfhepp made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/661

Full Changelog: https://github.com/pyscaffold/pyscaffold/compare/v4.3...v4.3.1
Source code(tar.gz)
Source code(zip)
v4.3(Jul 20, 2022)
This is a small incremental release, focusing on small improvements of existing functionality.

What's Changed

Removed wheel from the set of build dependencies in pyproject.toml (it is redundant since setuptools already includes it), #652.

Updated freebsd configuration in .cirrus.yml (with workaround for pipx in 2022Q3 repo), #657.

New Contributors

@mgorny made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/652

@cverrier made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/655

Full Changelog: https://github.com/pyscaffold/pyscaffold/compare/v4.2.3...v4.3
Source code(tar.gz)
Source code(zip)
v4.2.3(Jun 17, 2022)
What's Changed

Fix github action creating the demo-repo by, https://github.com/pyscaffold/pyscaffold/pull/644

Update GitHub actions, https://github.com/pyscaffold/pyscaffold/pull/645

Automatically create directory when saving config file, #648

Full Diff: https://github.com/pyscaffold/pyscaffold/compare/v4.2.2...v4.2.3
Source code(tar.gz)
Source code(zip)
v4.2.2(May 26, 2022)
I am happy to announce the new patch-level release: PyScaffold v4.2.2.

Main Changes

Update .github/workflows/ci.yml template, https://github.com/pyscaffold/pyscaffold/pull/637, https://github.com/pyscaffold/pyscaffold/pull/640

Change note in skeleton to emphasize it can be removed/renamed, https://github.com/pyscaffold/pyscaffold/pull/641

New Contributors

@eacheson made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/632

@kianmeng made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/635

Full Diff: https://github.com/pyscaffold/pyscaffold/compare/v4.2.1...v4.2.2
Source code(tar.gz)
Source code(zip)
v4.2.1(Mar 16, 2022)
I am happy to announce the new patch-level release: PyScaffold v4.2.1.

This release improves the GitLab CI configuration updated in v4.2.

What's Changed

Changed .gitlab-ci.yml template to work for GitLab Enterprise 14.7.4, #630

New Contributors

@baurmatt made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/630

Full Diff: https://github.com/pyscaffold/pyscaffold/compare/v4.2...v4.2.1
Source code(tar.gz)
Source code(zip)
v4.2(Mar 14, 2022)
I am happy to announce the new release: PyScaffold v4.2.

This release brings a lot of improvements, specially in terms of continuous integrations! The existing templates for Cirrus CI and GitLab CI were updated and PyScaffold can now generate configurations for GitHub Actions.

What's Changed

Added --github-actions extension, https://github.com/pyscaffold/pyscaffold/pull/619

Updated and improved --gitlab extension, https://github.com/pyscaffold/pyscaffold/pull/622

Updated and improved --cirrus extension, https://github.com/pyscaffold/pyscaffold/pull/625

Fixed tox -e publish example in docs by @bernhardschaefer, https://github.com/pyscaffold/pyscaffold/pull/627

Added colorama as a runtime dependency for windows, #624

New Contributors

@bernhardschaefer made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/627

Full Diff: https://github.com/pyscaffold/pyscaffold/compare/v4.1.5...v4.2
Source code(tar.gz)
Source code(zip)
v4.1.5(Feb 22, 2022)
I am happy to announce the new release: PyScaffold v4.1.5.

Main Changes

Add pyenv's .python-version into .gitignore, https://github.com/pyscaffold/pyscaffold/pull/576

Added more --very-verbose logging to make clearer what's going on, https://github.com/pyscaffold/pyscaffold/pull/578

Updated versions of containers in CI config, https://github.com/pyscaffold/pyscaffold/pull/583

Fixed coverage config template for namespaced packages, https://github.com/pyscaffold/pyscaffold/pull/610

Replaced internal appdirs dependency with platformdirs, https://github.com/pyscaffold/pyscaffold/pull/584

Documentation Changes

Mention python -m setuptools_scm as a form of debugging, https://github.com/pyscaffold/pyscaffold/pull/574

Mention setting the default branch in git in docs, https://github.com/pyscaffold/pyscaffold/pull/577

Fix documented path to pyscaffold/default.cfg, https://github.com/pyscaffold/pyscaffold/pull/580

New Contributors

@TaylorMonacelli made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/580

Full Diff: https://github.com/pyscaffold/pyscaffold/compare/v4.1.4...v4.1.5
Source code(tar.gz)
Source code(zip)
v4.1.4(Jan 13, 2022)
I am happy to announce the new bugfix release: PyScaffold v4.1.4.

Main Changes

Ensure build configuration produces sdist as it is needed by conda, https://github.com/pyscaffold/pyscaffold/issues/570

Documentation improvements in https://github.com/pyscaffold/pyscaffold/issues/567

Full Changelog: https://github.com/pyscaffold/pyscaffold/compare/v4.1.3...v4.1.4
Source code(tar.gz)
Source code(zip)
v4.1.3(Jan 11, 2022)
I am happy to announce the new bugfix release: PyScaffold v4.1.3.

Main Changes

Fix pre-commit error: The unauthenticated git protocol on port 9418 is no longer supported in https://github.com/pyscaffold/pyscaffold/pull/566

Source code(tar.gz)
Source code(zip)
v4.1.2(Jan 4, 2022)
I am happy to announce the new bugfix release: PyScaffold v4.1.2.

Main Changes

Prevent accidental creation of nested projects by @abravalheri in https://github.com/pyscaffold/pyscaffold/pull/545

Always log shell ops by @FlorianWilhelm in https://github.com/pyscaffold/pyscaffold/pull/559

Fix problem with Win10 shell by @FlorianWilhelm in https://github.com/pyscaffold/pyscaffold/pull/560

New Contributors

@git-afsantos made their first contribution in https://github.com/pyscaffold/pyscaffold/pull/552

Full Changelog: https://github.com/pyscaffold/pyscaffold/compare/v4.1.1...v4.1.2
Source code(tar.gz)
Source code(zip)
v4.1.1(Oct 18, 2021)
I am happy to announce the release of a new patch version: PyScaffold v4.1.1. This version solves bugs #506 and #516, and the main changes are:

Instruct users how to fix empty namespaces, persisted due to bug in PyScaffold < v4.1 (#508)

Better support for updating projects with multi-line descriptions (#509)

Extensions no longer can persist None values (#510).

Better error report when extension is not found during update (#512)

Allow comments (and prevent parsing errors) in dependency deduplication during update (#518)

Add license_files to setup.cfg template (#524)

Source code(tar.gz)
Source code(zip)
v4.1.1rc2(Oct 11, 2021)

Adds a partial fixes for issue #516. For the time being comments without indentation inside multiline options (very unlikely) are not handled due to ConfigUpdater limitations.
Source code(tar.gz)
Source code(zip)
v4.1.1rc1(Oct 1, 2021)

This is a bug fix related to #506.
Source code(tar.gz)
Source code(zip)
v4.1(Sep 22, 2021)
I am happy to announce the release of a new minor update: PyScaffold v4.1. The most notable changes are:

New linkcheck task for tox.ini, #456

New 0BSD license template.

New CONTRIBUTING.rst template, #376

New PyScaffold badge for README template, #473

Better coveralls integration for Cirrus CI, #449

Source code(tar.gz)
Source code(zip)
v4.1rc3(Sep 17, 2021)

Minor template updates since 4.1rc2 (#497, #498).
Source code(tar.gz)
Source code(zip)
v4.1rc2(Sep 14, 2021)

Source code(tar.gz)
Source code(zip)
v4.1rc1(Sep 8, 2021)

v4.1 will bring several improvements specially regarding CI automated tasks configuration and documentation.
Source code(tar.gz)
Source code(zip)
v4.0.2(May 26, 2021)
Restructured docs

Fix WSL2 installation problem, issue 440

Fix for interactive mode under Windows, issue 430

Source code(tar.gz)
Source code(zip)
v4.0.1(Mar 17, 2021)
The most notable changes in this patch-level release are:

Fix the warnings emitted by setuptools regarding kebab-cased-keys in setup.cfg

Remove broken checks for old versions of setuptools (fix #428)

Fix tox' build when running on conda environments.

Source code(tar.gz)
Source code(zip)
v4.0.1rc2(Mar 10, 2021)

This RC adds several improvements for running/building pyscaffold and extensions via conda (thanks to @maresb involvement) and fixes setuptools warnings for lower-kebab-case keys on setup.cfg (#418)
Source code(tar.gz)
Source code(zip)
v4.0.1rc1(Mar 5, 2021)

Update dependencies (ConfigUpdates, pyscaffoldext-django). The new version of each dependency fix certain edge cases, but not necessarily issues were found with PyScaffold v4 itself.

The release candidate is meant to give people sometime to play around with the changes in ConfigUpdater and report any bugs.
Source code(tar.gz)
Source code(zip)
v4.0(Mar 4, 2021)
It has been a long journey since PyScaffold v3 was released and a lot of things happened in the Python community especially regarding the packaging ecosystem...

We saw emerging a huge effort to standardise the build process and metadata with PEP 517 and PEP 518, a tendency to avoid pkg_resources (in favour of native namespaces with PEP 420, importlib.resources and importlib.metadata) and of course the deprecation of Python version 2. Moreover, having Python 3.6 as the lowest version officially supported by Python's core team, changed the way developers write their code: a bunch of new features are now available, allowing us to be more expressive and succinct (don't tell me you don't like to use f-strings).

As a result, the PyScaffold team decided to expand our previous ideas for improvements and also incorporate these changes within the ecosystem into a new, super cool, version of PyScaffold. So here I am, proud to officially announce the final release of PyScaffold v4 - now available in PyPI 🥳🎉

The complete list of changes introduced in this version is available at the official website together with a more detailed description of all the features, but I will try to summarise below some highlights of this release.

New Defaults

As a response to PEP 517 and PEP 518, PyScaffold v4 will automatically generate a pyproject.toml in the root of your repository. As a consequence, most of the tools in Python's build ecosystem will assume the distribution should be built in isolation (think of it as creating a virtual environment just for running python setup.py). In general, this change should reduce the chances of things going wrong and improve reproducibility, but it can also mean that you need to adapt a little bit your workflow.

To ease this transition, we are including by default a tox.ini in the root of your project, pre-configured with a lot of common tasks. If you have tox installed in your machine, you will be able to run:

tox -e docs # to build your documentation tox -e build # to build your package distribution tox -e publish # to test your project uploads correctly in test.pypi.org tox -e publish -- --repository pypi # to release your package to PyPI tox -av # to list all the tasks available

This is meant to be a replacement for deprecated setup.py commands such as:

python setup.py docs python setup.py tests # etc ...

We also are recommending using pip install . and pip install -e . instead of python setup.py install and python setup.py develop. In the future, it is very likely that running setup.py directly will be deprecated by setuptools, so we might as well start to get used to an interface that is unlikely to change.

Experimental and Exciting Features

Interactive Mode

Have you ever tried to use a CLI tool for the first time, or after a long period without using it, and faced a situation that forced you to go back and forth between typing your command and reading the --help text? It is usually not a great experience, especially when you have many options...

A few programs try to solve this problem by providing something called "interactive mode", which, most of the time, corresponds to a bunch of questions being prompted at the terminal. While this method is fine and familiar for most developers, it can get very tiring if the tool asks you more than 7 questions... and choosing by accident the wrong option in the last question, well, then you are going to hate having to reply to the same questions all over again...

Thus, we are trying something different in v4. When you activate the interactive mode with the -i or --interactive flags, PyScaffold will open your favourite text editor (the one you specify with the EDITOR environment variable), with an "editable version" of the --help text. A bit unusual right? But don't worry, it works very similarly to interactive rebases with git, i.e. you can comment options out by preceding the line with an # symbol, edit the values for the options (as shown in the example below), save and close the file then just wait for PyScaffold to run. This is how it looks:

myproject # path where to generate/update project # --name myproject # (or alternatively: -n) # installable name (as in `pip install`/PyPI, default: basename of # PROJECT_PATH) # --package myproject # (or alternatively: -p) # package name (as in `import`, default: NAME) --description 'Add a short description here!' # (or alternatively: -d) # package description # etc ...

Dynamically adapting to your workflow

One of the nice things about PyScaffold is that you can mix and match many tools according to your workflow. For example, if you like to run some quick tasks like linting or formatting the code before committing your changes, just add --pre-commit when generating your project with putup and PyScaffold will configure your project to use pre-commit.

In v4, we took that to a new level. Now you can dynamically update your project to include the supported tools, so you can gradually evolve and adapt your workflow.

Consider, for example, you have a project generated by PyScaffold, if at any point you decide to start testing it in Cirrus CI, just cd into your project root folder and run:

putup . --update --cirrus

Saving your favourite configuration

We all have favourites, right? And I guess after a while using PyScaffold you might tend to repeat a series of flags to express your preferences (like --pre-commit, --licence GPL-3.0, etc...). With v4 you can avoid retyping those options by saving a default configuration.

For example, if you create a new project by running:

putup myproject --pre-commit --cirrus --licence GPL-3.0 --save-config

The next time you create a project with putup, the --pre-commit, --cirrus and --licence GPL-3.0 options will be automatically applied, without the need of typing it again.

We hope PyScaffold users will find v4 easier to work with. We also invite everyone to have a look at the official extensions in our GitHub organisation, and if you are a bit more courageous, to have a look at our extensions guide.

In this release we offer a packaging experience up to date with the latest best practices and standardisation in the Python ecosystem, while maintaining the best backward compatibility possible. That is the spirit we plan to bring forward in the next releases.

I hope you all stay productive and have fun! 😉

Anderson Bravalheri & Florian Wilhelm

What is PyScaffold?

PyScaffold is the tool of choice for bootstrapping high quality Python packages, ready to be shared on PyPI and installable via pip. It is easy to use and encourages the adoption of the best tools and practices of the Python ecosystem, helping you and your team to stay sane, happy, and productive. The best part? It is stable and has been used by thousands of developers for over half a decade!

Why PyScaffold?

PyScaffold was created in 2014 and therefore is stable and battle tested, but yet constantly evolving to support its users' needs and the latest standards of the Python community.

With PyScaffold you can jump start your Python development with an incredibly smart project template, perfected throughout years of serious usage, that promotes the best practices in the Python ecosystem and ships with ready-to-use configuration for all the tools needed by the vast majority of Python developers.

If you are still not convinced, have a look on these other reasons and the extensive list of PyScaffold's features. And if you are curious, checkout our demo project, or install PyScaffold and type putup -h to get started.

Feedback

Issues and bugs: https://https://github.com/pyscaffold/pyscaffold/issues

Discussion, suggestions, questions: https://github.com/pyscaffold/pyscaffold/discussions

Source code(tar.gz)
Source code(zip)
v4.0rc2(Mar 4, 2021)

This version incorporates some feedback from users, fixes small bugs, and updates in documentation since since v4.0rc1
Source code(tar.gz)
Source code(zip)