the blessed package to manage your versions by scm tags

Overview

setuptools_scm

setuptools_scm handles managing your Python package versions in SCM metadata instead of declaring them as the version argument or in a SCM managed file.

Additionally setuptools_scm provides setuptools with a list of files that are managed by the SCM (i.e. it automatically adds all of the SCM-managed files to the sdist). Unwanted files must be excluded by discarding them via MANIFEST.in.

setuptools_scm support the following scm out of the box:

  • git
  • mercurial
https://tidelift.com/badges/package/pypi/setuptools-scm

pyproject.toml usage

The preferred way to configure setuptools_scm is to author settings in a tool.setuptools_scm section of pyproject.toml.

This feature requires Setuptools 42 or later, released in Nov, 2019. If your project needs to support build from sdist on older versions of Setuptools, you will need to also implement the setup.py usage for those legacy environments.

First, ensure that setuptools_scm is present during the project's built step by specifying it as one of the build requirements.

# pyproject.toml
[build-system]
requires = ["setuptools>=42", "wheel", "setuptools_scm[toml]>=3.4"]

Note that the toml extra must be supplied.

That will be sufficient to require setuptools_scm for projects that support PEP 518 (pip and pep517). Many tools, especially those that invoke setup.py for any reason, may continue to rely on setup_requires. For maximum compatibility with those uses, consider also including a setup_requires directive (described below in setup.py usage and setup.cfg).

To enable version inference, add this section to your pyproject.toml:

# pyproject.toml
[tool.setuptools_scm]

Including this section is comparable to supplying use_scm_version=True in setup.py. Additionally, include arbitrary keyword arguments in that section to be supplied to get_version(). For example:

# pyproject.toml

[tool.setuptools_scm]
write_to = "pkg/version.py"

setup.py usage

The following settings are considered legacy behavior and superseded by the pyproject.toml usage, but for maximal compatibility, projects may also supply the configuration in this older form.

To use setuptools_scm just modify your project's setup.py file like this:

  • Add setuptools_scm to the setup_requires parameter.
  • Add the use_scm_version parameter and set it to True.

For example:

from setuptools import setup
setup(
    ...,
    use_scm_version=True,
    setup_requires=['setuptools_scm'],
    ...,
)

Arguments to get_version() (see below) may be passed as a dictionary to use_scm_version. For example:

from setuptools import setup
setup(
    ...,
    use_scm_version = {
        "root": "..",
        "relative_to": __file__,
        "local_scheme": "node-and-timestamp"
    },
    setup_requires=['setuptools_scm'],
    ...,
)

You can confirm the version number locally via setup.py:

$ python setup.py --version

Note

If you see unusual version numbers for packages but python setup.py --version reports the expected version number, ensure [egg_info] is not defined in setup.cfg.

setup.cfg usage

If using setuptools 30.3.0 or greater, you can store setup_requires configuration in setup.cfg. However, use_scm_version must still be placed in setup.py. For example:

# setup.py
from setuptools import setup
setup(
    use_scm_version=True,
)
# setup.cfg
[metadata]
...

[options]
setup_requires =
  setuptools_scm
...

Important

Ensure neither the [metadata] version option nor the [egg_info] section are defined, as these will interfere with setuptools_scm.

You may also need to define a pyproject.toml file (PEP-0518) to ensure you have the required version of setuptools:

# pyproject.toml
[build-system]
requires = ["setuptools>=30.3.0", "wheel", "setuptools_scm"]

For more information, refer to the setuptools issue #1002.

Programmatic usage

In order to use setuptools_scm from code that is one directory deeper than the project's root, you can use:

from setuptools_scm import get_version
version = get_version(root='..', relative_to=__file__)

See setup.py Usage above for how to use this within setup.py.

Retrieving package version at runtime

If you have opted not to hardcode the version number inside the package, you can retrieve it at runtime from PEP-0566 metadata using importlib.metadata from the standard library (added in Python 3.8) or the importlib_metadata backport:

from importlib.metadata import version, PackageNotFoundError

try:
    __version__ = version("package-name")
except PackageNotFoundError:
    # package is not installed
    pass

Alternatively, you can use pkg_resources which is included in setuptools:

from pkg_resources import get_distribution, DistributionNotFound

try:
    __version__ = get_distribution("package-name").version
except DistributionNotFound:
     # package is not installed
    pass

This does place a runtime dependency on setuptools.

Usage from Sphinx

It is discouraged to use setuptools_scm from Sphinx itself, instead use pkg_resources after editable/real installation:

# contents of docs/conf.py
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])

The underlying reason is, that services like Read the Docs sometimes change the working directory for good reasons and using the installed metadata prevents using needless volatile data there.

Notable Plugins

setuptools_scm_git_archive
Provides partial support for obtaining versions from git archives that belong to tagged versions. The only reason for not including it in setuptools_scm itself is Git/GitHub not supporting sufficient metadata for untagged/followup commits, which is preventing a consistent UX.

Default versioning scheme

In the standard configuration setuptools_scm takes a look at three things:

  1. latest tag (with a version number)
  2. the distance to this tag (e.g. number of revisions since latest tag)
  3. workdir state (e.g. uncommitted changes since latest tag)

and uses roughly the following logic to render the version:

no distance and clean:
{tag}
distance and clean:
{next_version}.dev{distance}+{scm letter}{revision hash}
no distance and not clean:
{tag}+dYYYYMMDD
distance and not clean:
{next_version}.dev{distance}+{scm letter}{revision hash}.dYYYYMMDD

The next version is calculated by adding 1 to the last numeric component of the tag.

For Git projects, the version relies on git describe, so you will see an additional g prepended to the {revision hash}.

Semantic Versioning (SemVer)

Due to the default behavior it's necessary to always include a patch version (the 3 in 1.2.3), or else the automatic guessing will increment the wrong part of the SemVer (e.g. tag 2.0 results in 2.1.devX instead of 2.0.1.devX). So please make sure to tag accordingly.

Note

Future versions of setuptools_scm will switch to SemVer by default hiding the the old behavior as an configurable option.

Builtin mechanisms for obtaining version numbers

  1. the SCM itself (git/hg)
  2. .hg_archival files (mercurial archives)
  3. PKG-INFO

Note

Git archives are not supported due to Git shortcomings

File finders hook makes most of MANIFEST.in unnecessary

setuptools_scm implements a file_finders entry point which returns all files tracked by your SCM. This eliminates the need for a manually constructed MANIFEST.in in most cases where this would be required when not using setuptools_scm, namely:

  • To ensure all relevant files are packaged when running the sdist command.
  • When using include_package_data to include package data as part of the build or bdist_wheel.

MANIFEST.in may still be used: anything defined there overrides the hook. This is mostly useful to exclude files tracked in your SCM from packages, although in principle it can be used to explicitly include non-tracked files too.

Configuration parameters

In order to configure the way use_scm_version works you can provide a mapping with options instead of a boolean value.

The currently supported configuration keys are:

root:

Relative path to cwd, used for finding the SCM root; defaults to .

version_scheme:

Configures how the local version number is constructed; either an entrypoint name or a callable.

local_scheme:

Configures how the local component of the version is constructed; either an entrypoint name or a callable.

write_to:

A path to a file that gets replaced with a file containing the current version. It is ideal for creating a version.py file within the package, typically used to avoid using pkg_resources.get_distribution (which adds some overhead).

Warning

Only files with .py and .txt extensions have builtin templates, for other file types it is necessary to provide write_to_template.

write_to_template:

A newstyle format string that is given the current version as the version keyword argument for formatting.

relative_to:

A file from which the root can be resolved. Typically called by a script or module that is not in the root of the repository to point setuptools_scm at the root of the repository by supplying __file__.

tag_regex:
A Python regex string to extract the version part from any SCM tag.

The regex needs to contain either a single match group, or a group named version, that captures the actual version information.

Defaults to the value of setuptools_scm.config.DEFAULT_TAG_REGEX (see config.py).

parentdir_prefix_version:

If the normal methods for detecting the version (SCM version, sdist metadata) fail, and the parent directory name starts with parentdir_prefix_version, then this prefix is stripped and the rest of the parent directory name is matched with tag_regex to get a version string. If this parameter is unset (the default), then this fallback is not used.

This is intended to cover GitHub's "release tarballs", which extract into directories named projectname-tag/ (in which case parentdir_prefix_version can be set e.g. to projectname-).

fallback_version:

A version string that will be used if no other method for detecting the version worked (e.g., when using a tarball with no metadata). If this is unset (the default), setuptools_scm will error if it fails to detect the version.

parse:

A function that will be used instead of the discovered SCM for parsing the version. Use with caution, this is a function for advanced use, and you should be familiar with the setuptools_scm internals to use it.

git_describe_command:

This command will be used instead the default git describe command. Use with caution, this is a function for advanced use, and you should be familiar with the setuptools_scm internals to use it.

Defaults to the value set by setuptools_scm.git.DEFAULT_DESCRIBE (see git.py).

To use setuptools_scm in other Python code you can use the get_version function:

from setuptools_scm import get_version
my_version = get_version()

It optionally accepts the keys of the use_scm_version parameter as keyword arguments.

Example configuration in setup.py format:

from setuptools import setup

setup(
    use_scm_version={
        'write_to': 'version.py',
        'write_to_template': '__version__ = "{version}"',
        'tag_regex': r'^(?P<prefix>v)?(?P<version>[^\+]+)(?P<suffix>.*)?$',
    }
)

Environment variables

SETUPTOOLS_SCM_PRETEND_VERSION:

when defined and not empty, its used as the primary source for the version number in which case it will be a unparsed string

SETUPTOOLS_SCM_PRETEND_VERSION_FOR_${UPPERCASED_DIST_NAME}:
 

when defined and not empty, its used as the primary source for the version number in which case it will be a unparsed string

it takes precedence over SETUPTOOLS_SCM_PRETEND_VERSION

SETUPTOOLS_SCM_DEBUG:

when defined and not empty, a lot of debug information will be printed as part of setuptools_scm operating

SOURCE_DATE_EPOCH:

when defined, used as the timestamp from which the node-and-date and node-and-timestamp local parts are derived, otherwise the current time is used (https://reproducible-builds.org/docs/source-date-epoch/)

SETUPTOOLS_SCM_IGNORE_VCS_ROOTS:

when defined, a os.pathsep separated list of directory names to ignore for root finding

Extending setuptools_scm

setuptools_scm ships with a few setuptools entrypoints based hooks to extend its default capabilities.

Adding a new SCM

setuptools_scm provides two entrypoints for adding new SCMs:

setuptools_scm.parse_scm
A function used to parse the metadata of the current workdir using the name of the control directory/file of your SCM as the entrypoint's name. E.g. for the built-in entrypoint for git the entrypoint is named .git and references setuptools_scm.git:parse

The return value MUST be a setuptools_scm.version.ScmVersion instance created by the function setuptools_scm.version:meta.

setuptools_scm.files_command

Either a string containing a shell command that prints all SCM managed files in its current working directory or a callable, that given a pathname will return that list.

Also use then name of your SCM control directory as name of the entrypoint.

Version number construction

setuptools_scm.version_scheme

Configures how the version number is constructed given a setuptools_scm.version.ScmVersion instance and should return a string representing the version.

Available implementations:

guess-next-dev: Automatically guesses the next development version (default). Guesses the upcoming release by incrementing the pre-release segment if present, otherwise by incrementing the micro segment. Then appends .devN. In case the tag ends with .dev0 the version is not bumped and custom .devN versions will trigger a error.
post-release: generates post release versions (adds .postN)
python-simplified-semver: Basic semantic versioning. Guesses the upcoming release by incrementing the minor segment and setting the micro segment to zero if the current branch contains the string 'feature', otherwise by incrementing the micro version. Then appends .devN. Not compatible with pre-releases.
release-branch-semver: Semantic versioning for projects with release branches. The same as guess-next-dev (incrementing the pre-release or micro segment) if on a release branch: a branch whose name (ignoring namespace) parses as a version that matches the most recent tag up to the minor segment. Otherwise if on a non-release branch, increments the minor segment and sets the micro segment to zero, then appends .devN.
no-guess-dev: Does no next version guessing, just adds .post1.devN
setuptools_scm.local_scheme

Configures how the local part of a version is rendered given a setuptools_scm.version.ScmVersion instance and should return a string representing the local version. Dates and times are in Coordinated Universal Time (UTC), because as part of the version, they should be location independent.

Available implementations:

node-and-date: adds the node on dev versions and the date on dirty workdir (default)
node-and-timestamp: like node-and-date but with a timestamp of the form {:%Y%m%d%H%M%S} instead
dirty-tag: adds +dirty if the current workdir has changes
no-local-version: omits local version, useful e.g. because pypi does not support it

Importing in setup.py

To support usage in setup.py passing a callable into use_scm_version is supported.

Within that callable, setuptools_scm is available for import. The callable must return the configuration.

# content of setup.py
import setuptools

def myversion():
    from setuptools_scm.version import get_local_dirty_tag
    def clean_scheme(version):
        return get_local_dirty_tag(version) if version.dirty else '+clean'

    return {'local_scheme': clean_scheme}

setup(
    ...,
    use_scm_version=myversion,
    ...
)

Note on testing non-installed versions

While the general advice is to test against a installed version, some environments require a test prior to install,

$ python setup.py egg_info
$ PYTHONPATH=$PWD:$PWD/src pytest

Interaction with Enterprise Distributions

Some enterprise distributions like RHEL7 and others ship rather old setuptools versions due to various release management details.

On such distributions one might observe errors like:

:code:setuptools_scm.version.SetuptoolsOutdatedWarning: your setuptools is too old (<12)

In those case its typically possible to build by using a sdist against setuptools_scm<2.0. As those old setuptools versions lack sensible types for versions, modern setuptools_scm is unable to support them sensibly.

In case the project you need to build can not be patched to either use old setuptools_scm, its still possible to install a more recent version of setuptools in order to handle the build and/or install the package by using wheels or eggs.

Code of Conduct

Everyone interacting in the setuptools_scm project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the PSF Code of Conduct.

Security Contact

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

Comments
  • ImportError: No module named file_finder_hg (when not installed)

    ImportError: No module named file_finder_hg (when not installed)

    There are two points where a Debian packages might get tested : at build time (it gets build then tested in-place), or as quality assurance after the package gets installed.

    If I disable build-time tests, my packaging is ok and passes the quality tests.

    But the build-time tests fail. In fact, all the testing_file_finder.py tests fail, because of an ImportError on the file_finder_hg module. And if I patch to remove file_finder_hg, they fail because file_finder_git isn't found. So in fact it looks like importing of files_command fails on a non-installed package.

    question 
    opened by SnarkBoojum 44
  • Missing module name tomli

    Missing module name tomli

    Since the release of setuptools_scm 6.1.1 a few minutes ago, our jenkins jobs are failing on the following error:

    Traceback (most recent call last):
      File "/var/lib/jenkins/workspace/nidar-orchid_master/setup.py", line 7, in <module>
        setuptools.setup(
      File "/root/.pyenv/versions/3.9.5/lib/python3.9/site-packages/setuptools/__init__.py", line 153, in setup
        return distutils.core.setup(**attrs)
      File "/root/.pyenv/versions/3.9.5/lib/python3.9/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/root/.pyenv/versions/3.9.5/lib/python3.9/site-packages/setuptools/dist.py", line 434, in __init__
        _Distribution.__init__(self, {
      File "/root/.pyenv/versions/3.9.5/lib/python3.9/distutils/dist.py", line 292, in __init__
        self.finalize_options()
      File "/root/.pyenv/versions/3.9.5/lib/python3.9/site-packages/setuptools/dist.py", line 743, in finalize_options
        ep(self)
      File "/var/lib/jenkins/workspace/nidar-orchid_master/.eggs/setuptools_scm-6.1.1-py3.9.egg/setuptools_scm/integration.py", line 52, in infer_version
        config = Configuration.from_file(dist_name=dist_name)
      File "/var/lib/jenkins/workspace/nidar-orchid_master/.eggs/setuptools_scm-6.1.1-py3.9.egg/setuptools_scm/config.py", line 187, in from_file
        defn = _load_toml(data)
      File "/var/lib/jenkins/workspace/nidar-orchid_master/.eggs/setuptools_scm-6.1.1-py3.9.egg/setuptools_scm/config.py", line 59, in _lazy_tomli_load
        from tomli import loads
    ModuleNotFoundError: No module named 'tomli'
    

    Maybe a missing dependency somewhere?

    opened by RouquinBlanc 39
  • pip install -r requirements.txt fails to

    pip install -r requirements.txt fails to "setuptools-scm was unable to detect version for '/tmp'"

    Version: 1.15.0

    I have requirements declared in setup.py, so with requirements.txt file of:

    .
    

    pip install -r requirement.txt:

    Processing /home/musttu/Code/lib/wires/aws
        Complete output from command python setup.py egg_info:
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
          File "/tmp/pip-pgsLbN-build/setup.py", line 31, in <module>
            'pastry-common==3.2.1.dev30',
          File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
            _setup_distribution = dist = klass(attrs)
          File "/home/musttu/Code/virtualenvs/wires/local/lib/python2.7/site-packages/setuptools/dist.py", line 318, in __init__
            _Distribution.__init__(self, attrs)
          File "/usr/lib/python2.7/distutils/dist.py", line 287, in __init__
            self.finalize_options()
          File "/home/musttu/Code/virtualenvs/wires/local/lib/python2.7/site-packages/setuptools/dist.py", line 376, in finalize_options
            ep.load()(self, ep.name, value)
          File "/home/musttu/Code/virtualenvs/wires/local/lib/python2.7/site-packages/setuptools_scm/integration.py", line 19, in version_keyword
            dist.metadata.version = get_version(**value)
          File "/home/musttu/Code/virtualenvs/wires/local/lib/python2.7/site-packages/setuptools_scm/__init__.py", line 117, in get_version
            parsed_version = _do_parse(root, parse)
          File "/home/musttu/Code/virtualenvs/wires/local/lib/python2.7/site-packages/setuptools_scm/__init__.py", line 95, in _do_parse
            "use git+https://github.com/user/proj.git#egg=proj" % root)
        LookupError: setuptools-scm was unable to detect version for '/tmp'.
    

    I don't believe it's possible to fix this within setuptools-scm, however. If pip uses /tmp for temporarily building/handling the package, there's simply no version information available and nothing to be done. Correct? Would you have any guesses if it's possible to make it work on pip side?

    There is a related ticket in https://github.com/pypa/setuptools_scm/issues/46 but I think that was closed because user tried to install an sdist there.

    bug enhancement help wanted regression 
    opened by tuukkamustonen 31
  • 6.4.0: pytest is failing in `testing/test_integration.py::test_provides_toml_exta` unit

    6.4.0: pytest is failing in `testing/test_integration.py::test_provides_toml_exta` unit

    I'm trying to package your module as an rpm package. So I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.

    • python3 -sBm build -w --no-isolation
    • because I'm calling build with --no-isolation I'm using during all processes oly locally installed modules
    • install .whl file in </install/prefix>
    • run pytest with PYTHONPATH pointing to sitearch and sitelib inside </install/prefix>

    Here is pytest output:

    + PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-setuptools_scm-6.4.0-2.fc35.x86_64//usr/lib/python3.8/site-packages
    + pytest -ra --ignore testing/test_hg_git.py
    =========================================================================== test session starts ============================================================================
    platform linux -- Python 3.8.12, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
    setuptools version 60.5.4.post20220117 from '/usr/lib/python3.8/site-packages/setuptools/__init__.py'
    setuptools_scm version 6.4.0 from '/home/tkloczko/rpmbuild/BUILDROOT/python-setuptools_scm-6.4.0-2.fc35.x86_64/usr/lib/python3.8/site-packages/setuptools_scm/__init__.py'
    rootdir: /home/tkloczko/rpmbuild/BUILD/setuptools_scm-6.4.0, configfile: tox.ini, testpaths: testing
    collected 236 items
    
    testing/test_basic_api.py .................                                                                                                                          [  7%]
    testing/test_config.py ...........                                                                                                                                   [ 11%]
    testing/test_file_finder.py .s.s.s.s.s.s.s.s.s.s.s..ss.s.s.s.s.s                                                                                                     [ 27%]
    testing/test_functions.py .........................                                                                                                                  [ 37%]
    testing/test_git.py ...............x...........X.....                                                                                                                [ 51%]
    testing/test_integration.py ...............F                                                                                                                         [ 58%]
    testing/test_main.py ....                                                                                                                                            [ 60%]
    testing/test_mercurial.py ssssssssssssssss                                                                                                                           [ 66%]
    testing/test_regressions.py ....s                                                                                                                                    [ 69%]
    testing/test_setuptools_support.py sssssssssssssssssssssssssssss                                                                                                     [ 81%]
    testing/test_version.py .........................................x..                                                                                                 [100%]
    
    ================================================================================= FAILURES =================================================================================
    _________________________________________________________________________ test_provides_toml_exta __________________________________________________________________________
    
        @pytest.mark.issue(611)
        def test_provides_toml_exta():
            try:
                from importlib.metadata import distribution
            except ImportError:
                from importlib_metadata import distribution
    
            dist = distribution("setuptools_scm")
    >       assert "toml" in dist.metadata["Provides-Extra"]
    E       AssertionError: assert 'toml' in 'test'
    
    testing/test_integration.py:152: AssertionError
    ========================================================================= short test summary info ==========================================================================
    SKIPPED [18] testing/test_file_finder.py:24: hg executable not found
    SKIPPED [5] testing/test_mercurial.py:37: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:49: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:55: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:69: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:97: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:112: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:122: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:147: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:152: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:159: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:171: hg executable not found
    SKIPPED [1] testing/test_mercurial.py:181: hg executable not found
    SKIPPED [1] testing/test_regressions.py:84: this bug is only valid on windows
    SKIPPED [29] testing/test_setuptools_support.py:75: testing on legacy setuptools disabled, pass --test-legacy to run them
    XFAIL testing/test_git.py::test_git_worktree_support
      sometimes relative path results
    XFAIL testing/test_version.py::test_calver_by_date_semver[SemVer dirty]
    XPASS testing/test_git.py::test_non_dotted_version https://github.com/pypa/setuptools_scm/issues/449
    FAILED testing/test_integration.py::test_provides_toml_exta - AssertionError: assert 'toml' in 'test'
    ===================================================== 1 failed, 168 passed, 64 skipped, 2 xfailed, 1 xpassed in 19.45s =====================================================
    
    bug 
    opened by kloczek 25
  • Support working on a Git repository with hg-git

    Support working on a Git repository with hg-git

    Mercurial can be used as a Git client with hg-git. Then, one would like to get the same version as with Git (in particular, with Git sha). I tried to implement that in this PR. It's an early draft without tests!

    This PR fixes #530.

    opened by paugier 24
  • errors with conda build

    errors with conda build

    Hello, I created a recipe for a project and I'm using setuptools_scm. For this project my source section of my recipe is like:

    source:
      git_tag: my-branch
      git_url: PATH-to-git.git
    

    my script section is:

      script:
        - python -m pip install --no-deps --ignore-installed src/pythonKarabo
    

    where is located my setup.py

    When I try to build that using conda build I'm facing this error:

        Complete output from command python setup.py egg_info:
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
          File "/tmp/pip-mmcl8gq4-build/setup.py", line 72, in <module>
            'TestDevice=karabo.middlelayer_api.tests.bounddevice:TestDevice'
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/site-packages/setuptools/__init__.py", line 131, in setup
            return distutils.core.setup(**attrs)
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/distutils/core.py", line 108, in setup
            _setup_distribution = dist = klass(attrs)
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/site-packages/setuptools/dist.py", line 370, in __init__
            k: v for k, v in attrs.items()
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/distutils/dist.py", line 281, in __init__
            self.finalize_options()
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/site-packages/setuptools/dist.py", line 529, in finalize_options
            ep.load()(self, ep.name, value)
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/site-packages/setuptools_scm/integration.py", line 22, in version_keyword
            dist.metadata.version = get_version(**value)
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 119, in get_version
            parsed_version = _do_parse(root, parse)
          File "/home/trevisan/miniconda3/conda-bld/python-karabo_1531408265571/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 97, in _do_parse
            "use git+https://github.com/user/proj.git#egg=proj" % root)
    
       LookupError: setuptools-scm was unable to detect version for '/tmp/pip-mmcl8gq4-build'.
        
        Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
        
        For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
    
    
    opened by marcelotrevisani 23
  • Built wheel is invalid: Metadata 1.2 mandates PEP 440 version, but '0.0.2.dev1.post1.dev2-g8fd2842' is not

    Built wheel is invalid: Metadata 1.2 mandates PEP 440 version, but '0.0.2.dev1.post1.dev2-g8fd2842' is not

    Attempting to run tox tests on a library I am building is throwing the below error:

    Processing ./.tox/.tmp/package/1/python-step-series-0.0.2.dev1.post1.dev2-g8fd2842.tar.gz
      Installing build dependencies: started
      Installing build dependencies: finished with status 'done'
      Getting requirements to build wheel: started
      Getting requirements to build wheel: finished with status 'done'
        Preparing wheel metadata: started
        Preparing wheel metadata: finished with status 'done'
    Building wheels for collected packages: python-step-series
      Building wheel for python-step-series (PEP 517): started
      Building wheel for python-step-series (PEP 517): finished with status 'done'
      Created wheel for python-step-series: filename=python_step_series-0.0.2.dev1.post1.dev2_g8fd2842-py3-none-any.whl size=18021 sha256=7c172e5d554075b0c12255e06be171c067edf4569bb621c5fa573070d39d581d
      Stored in directory: /home/user/.cache/pip/wheels/d1/5f/e0/84fd855c772a59469c7065c94464233a7532667a9c94430803
      WARNING: Built wheel for python-step-series is invalid: Metadata 1.2 mandates PEP 440 version, but '0.0.2.dev1.post1.dev2-g8fd2842' is not
    Failed to build python-step-series
    ERROR: Could not build wheels for python-step-series which use PEP 517 and cannot be installed directly
    

    I believe it is being caused by the warning I've titled this issue with. I just started getting this error this morning and am completely stuck on why I am all of a sudden seeing it. I looked at #278 as it seemed similar, but was not. Regardless, as like in that issue, here are the outputs for git tag, git describe and git status:

    git tag:

    0.0.2dev0
    0.0.2dev1
    v0.0.1
    

    git describe:

    0.0.2dev0-6-g8fd2842
    

    git status:

    On branch 0.0.2
    Your branch is up to date with 'origin/0.0.2'.
    
    nothing to commit, working tree clean
    

    Curiously, creating a new tag (i.e. 0.0.2dev2) will allow me to run the tests until my working tree gets dirty again, so creating a new tag every time I want to test isn't viable nor proper.

    I am 100% stuck, so please let me know what I can do to rectify this if you are able. Jules

    status: needs_information 
    opened by JulianOrteil 22
  • Incorrect removal of dash in case of pre-release tag string ?

    Incorrect removal of dash in case of pre-release tag string ?

    I found this today: 1.0.0-rc1 becomes 1.0.0rc1, see details here https://github.com/smarie/python-getversion/issues/10

    The underlying error is due to pkg_resources that removes the pre-release dash automatically in its string representation since version 0.6a9.

    However as suggested in my conclusions I think that the issue should probably better be fixed in the default scheme of setuptools_scm because faithfulness to git tags and compliance with semver for example, is probably a higher concern for you than for pkg_resources.

    Thanks again for this great package !

    enhancement help wanted 
    opened by smarie 21
  • Versions according to the Debian Policy Manual

    Versions according to the Debian Policy Manual

    I'm currently using setuptools-scm with pybuild to build debian packages. The problem I'm facing right now is that we sometimes have tildes (~) in the version number, which doesn't seem to be supported.

    When enabling the debug logs I get:

    tag 0.8.1~alpha3
    version <LegacyVersion('0.8.1~alpha3')>
    version None
    

    Along with the following traceback:

    Traceback (most recent call last):
      File "setup.py", line 51, in <module>
        entry_points={"console_scripts": ["sts = sts.__main__:main"]},
      File "/usr/lib/python3.4/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 320, in __init__
        _Distribution.__init__(self, attrs)
      File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__
        self.finalize_options()
      File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 387, in finalize_options
        ep.load()(self, ep.name, value)
      File "/usr/lib/python3/dist-packages/setuptools_scm/integration.py", line 19, in version_keyword
        dist.metadata.version = get_version(**value)
      File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 117, in get_version
        parsed_version = _do_parse(root, parse)
      File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 66, in _do_parse
        return meta(pretended)
      File "/usr/lib/python3/dist-packages/setuptools_scm/version.py", line 86, in meta
        assert tag is not None, 'cant parse version %s' % tag
    AssertionError: cant parse version None
    

    What's the correct way to workaround this? Would it be possible to support versions according to the Debian Versioning Policies?

    See: Debian Policy Manual for the versioning policies.

    enhancement help wanted deferred 
    opened by timofurrer 20
  • Regression: get_version works for 1.10.1 and 1.11.1, but not 1.13.1

    Regression: get_version works for 1.10.1 and 1.11.1, but not 1.13.1

    Summary

    setuptools_scm 1.13.1 fails for several of my projects. 1.10.1 and 1.11.1 worked fine. The ultimate error is (full traceback below):

      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/version.py", line 86, in meta
        assert tag is not None, 'cant parse version %s' % tag
    AssertionError: cant parse version None
    
    

    Python 3.5.2, Ubuntu 16.04, various versions of setuptools_scm (see below).

    This error appears to occur only for head revisions on several repos. Affected repos use hg-git, although I have no evidence that that's related.

    Reproduction

    snafu$ hg clone [email protected]:biocommons/bioutils.git
    destination directory: bioutils
    importing git objects into hg
    updating to branch default
    41 files updated, 0 files merged, 0 files removed, 0 files unresolved
    
    snafu$ cd bioutils/
    
    snafu$ pyvenv venv
    
    snafu$ source venv/bin/activate
    
    (venv) snafu$ pip install --upgrade pip setuptools
    Collecting pip
      Using cached pip-9.0.1-py2.py3-none-any.whl
    Collecting setuptools
      Using cached setuptools-28.8.0-py2.py3-none-any.whl
    Installing collected packages: pip, setuptools
      Found existing installation: pip 8.1.1
        Uninstalling pip-8.1.1:
          Successfully uninstalled pip-8.1.1
      Found existing installation: setuptools 20.7.0
        Uninstalling setuptools-20.7.0:
          Successfully uninstalled setuptools-20.7.0
    Successfully installed pip-9.0.1 setuptools-28.8.0
    
    # recent commits, with any tags
    (venv) snafu$ hg log -l 7 -G -T '{rev} {node|short} {tags}'
    @  59 4aac87427260 default/default/master default/master tip
    |
    o  58 f9ca4a4c9c1c 0.2.0a2
    |
    o  57 f7d97e9493ae
    |
    o  56 57709bd798a4
    |
    o  55 019f38efb5c2
    |
    o  54 12c36903cb55 0.2.0a1
    |
    o  53 6bf205dc9ec0
    
    # generate a table of get_version results for the above commits and setuptools_scm 1.10.1, 1.11.1, 1.13.1
    (venv) snafu$ for r in 4aac f9ca f7d9 5770 019f 12c3 6bf2; do hg up -q $r; echo -n $(hg id -it); for v in 1.10.1 1.11.1 1.13.1; do pip install setuptools_scm==$v 1>/dev/null 2>&1; echo -n ,$(python -c 'from setuptools_scm import get_version; print(get_version())' 2>/dev/null | tail -1); done; echo; done >|data
    
    (venv) snafu$ column -ts, <data
    4aac87427260 default/default/master default/master tip  0.2.0a2                     0.2.0a2
    f9ca4a4c9c1c 0.2.0a2                                    0.2.0a2                     0.2.0a2                     0.2.0a2
    f7d97e9493ae                                            0.2.0a2.dev3+nf7d97e9493ae  0.2.0a2.dev3+nf7d97e9493ae  0.2.0a2.dev3+nf7d97e9493ae
    57709bd798a4                                            0.2.0a2.dev2+n57709bd798a4  0.2.0a2.dev2+n57709bd798a4  0.2.0a2.dev2+n57709bd798a4
    019f38efb5c2                                            0.2.0a1                     0.2.0a1                     0.2.0a1
    12c36903cb55 0.2.0a1                                    0.2.0a1                     0.2.0a1                     0.2.0a1
    6bf205dc9ec0                                            0.1.4.dev4+n6bf205dc9ec0    0.1.4.dev4+n6bf205dc9ec0    0.1.4.dev4+n6bf205dc9ec0
    
    
    

    Columns are 1) changeset + tags, 2) 1.10.1 get_version, 3) 1.11.1 get_version, 4) 1.13.1 get_version

    Example Tracebacks

    These are all collected for the same bioutils commit (changeset 4aac87427260).

    1.13.1

    (venv) snafu$ pip install setuptools_scm==1.13.1; python -c 'from setuptools_scm import get_version; print(get_version())'
    Collecting setuptools_scm==1.13.1
      Using cached setuptools_scm-1.13.1-py2.py3-none-any.whl
    Installing collected packages: setuptools-scm
    Successfully installed setuptools-scm-1.13.1
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/__init__.py", line 117, in get_version
        parsed_version = _do_parse(root, parse)
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/__init__.py", line 82, in _do_parse
        version = version_from_scm(root)
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/__init__.py", line 31, in version_from_scm
        return _version_from_entrypoint(root, 'setuptools_scm.parse_scm')
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/__init__.py", line 37, in _version_from_entrypoint
        return ep.load()(root)
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/hg.py", line 43, in parse
        return _hg_tagdist_normalize_tagcommit(root, tag, dist, node)
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/hg.py", line 17, in _hg_tagdist_normalize_tagcommit
        return meta(tag, distance=dist, node=node, dirty=dirty)
      File "/home/reece/projects/biocommons/bioutils/venv/lib/python3.5/site-packages/setuptools_scm/version.py", line 86, in meta
        assert tag is not None, 'cant parse version %s' % tag
    AssertionError: cant parse version None
    

    1.11.1

    (venv) snafu$ pip install setuptools_scm==1.11.1; python -c 'from setuptools_scm import get_version; print(get_version())'
    Collecting setuptools_scm==1.11.1
      Using cached setuptools_scm-1.11.1-py2.py3-none-any.whl
    Installing collected packages: setuptools-scm
      Found existing installation: setuptools-scm 1.13.1
        Uninstalling setuptools-scm-1.13.1:
          Successfully uninstalled setuptools-scm-1.13.1
    Successfully installed setuptools-scm-1.11.1
    0.2.0a3.dev2+n932c0cfb2774
    

    1.10.1

    (venv) snafu$ pip install setuptools_scm==1.10.1; python -c 'from setuptools_scm import get_version; print(get_version())'
    Collecting setuptools_scm==1.10.1
      Using cached setuptools_scm-1.10.1-py2.py3-none-any.whl
    Installing collected packages: setuptools-scm
      Found existing installation: setuptools-scm 1.11.1
        Uninstalling setuptools-scm-1.11.1:
          Successfully uninstalled setuptools-scm-1.11.1
    Successfully installed setuptools-scm-1.10.1
    0.2.0a3.dev2+n932c0cfb2774
    
    
    regression 
    opened by reece 20
  • Cannot build package from a github download

    Cannot build package from a github download

    See https://github.com/django-guardian/django-guardian/issues/445 @brianmay wrote there:

    Yes, this is a known limitation in setuptools-scm. I would not recommend using development versions in this way; this is what releases are for.

    There are many cases where

    • I cannot wait for some official release
    • I do not have git installed on the installation machine

    This is rather annoying. Should this tools be avoided for git repos?

    Is the only way in these cases for a git-using lib using setuptools_scm to maintain a fork?

    enhancement help wanted question 
    opened by pombredanne 20
  • Add `strip-dev` as `get_version` argument

    Add `strip-dev` as `get_version` argument

    Hi, I'm @dariocurr and I am part of @buildnn.

    We are trying to integrate setuptools-scm into our CI/CD, and it would be really helpful if we could use the strip-dev option through the python interface as well as from the CLI. That's why, with a few modifications, I made it possible.

    I added some tests to make sure everything works as it should

    opened by dariocurr 2
  • unable to detect version

    unable to detect version

    Did something that was fixed already break again for this?

    I have a debian buster vagrant machine that throws the "unable to detect version" now and it used to always work.

    tox  # works
    fakeroot -u tox  # fails with "unable to detect version"
    

    A debian bullseye vagrant machine with a very similar setup works.

    https://github.com/borgbackup/borg/pull/7224 this is the code I used (see Vagrantfile).

    BTW: on misc. ubuntu dists this is broken since a longer while.

    Traceback from the buster machine:

    (borg-env) vagrant@buster:/vagrant/borg/borg$ borg -V
    borg 1.2.3
    (borg-env) vagrant@buster:/vagrant/borg/borg$ fakeroot -u tox
    GLOB sdist-make: /vagrant/borg/borg/setup.py
    ERROR: invocation failed (exit code 1), logfile: /vagrant/borg/borg/.tox/log/GLOB-0.log
    ================================================================================= log start ==================================================================================
    Detected OpenSSL [via pkg-config]
    Detected and preferring liblz4 [via pkg-config]
    Detected and preferring libzstd [via pkg-config]
    Using bundled xxhash
    Traceback (most recent call last):
      File "/vagrant/borg/borg/setup.py", line 263, in <module>
        setup(
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools/__init__.py", line 87, in setup
        return distutils.core.setup(**attrs)
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools/_distutils/core.py", line 109, in setup
        _setup_distribution = dist = klass(attrs)
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools/dist.py", line 462, in __init__
        _Distribution.__init__(
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools/_distutils/dist.py", line 293, in __init__
        self.finalize_options()
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools/dist.py", line 886, in finalize_options
        ep(self)
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools/dist.py", line 907, in _finalize_setup_keywords
        ep.load()(self, ep.name, value)
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools_scm/integration.py", line 75, in version_keyword
        _assign_version(dist, config)
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools_scm/integration.py", line 51, in _assign_version
        _version_missing(config)
      File "/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/lib/python3.9/site-packages/setuptools_scm/__init__.py", line 106, in _version_missing
        raise LookupError(
    LookupError: setuptools-scm was unable to detect version for /vagrant/borg/borg.
    
    Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
    
    For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
    
    ================================================================================== log end ===================================================================================
    ERROR: FAIL could not package project - v = InvocationError('/home/vagrant/.pyenv/versions/3.9.16/envs/borg-env/bin/python3.9 setup.py sdist --formats=zip --dist-dir .tox/dist', 1)
    
    opened by ThomasWaldmann 7
  • Hidden files no longer required for git archive?

    Hidden files no longer required for git archive?

    In the docs under Git archives, it states that in order for the version number to be retrieved from tags, some special content is required in 2 files: .git_archival.txt and .gitattributes.

    However, after comparing notes with a colleague, it seems like the two files might not actually be required. I tried removing them and I think everything is working properly. Am I missing something, or can these files be dispensed with now?

    The project I'm building: https://github.com/kwinkunks/unmap (except without those 2 files)

    The content of unmap/_version.py (which is not in the archive) is being updated, e.g.:

    # coding: utf-8
    # file generated by setuptools_scm
    # don't change, don't track in version control
    __version__ = version = '0.1.3rc2.dev1+g77e7a8a.d20221205'
    __version_tuple__ = version_tuple = (0, 1, 3, 'dev1', 'g77e7a8a.d20221205')
    

    The versioning code is in unmap/__init__.py.

    question status: needs_information 
    opened by kwinkunks 1
  • setuptools_scm silently reports garbage version with partial Git clone

    setuptools_scm silently reports garbage version with partial Git clone

    Readthedocs clones with

    git clone --no-single-branch --depth 50 https://github.com/snek5000/snek5000.git
    cd snek5000
    git checkout --force origin/main
    git clean -d -f -f
    

    With such clone,

    $ git --git-dir .git describe --dirty --tags --long
    fatal: No tags can describe '2a7b9f0b372163f19d0af2dc1cb6752528310530'.
    Try --always, or create some tags.
    

    In contrast, git tag gives the right list of tags. Anyway, setuptools_scm bases its analysis on git describe so it gives a wrong version (something like 0.1.dev173+g2a7b9f0).

    To get the right version, I need to run:

    $ git pull --unshallow
    remote: Enumerating objects: 298, done.
    remote: Counting objects: 100% (267/267), done.
    remote: Compressing objects: 100% (84/84), done.
    remote: Total 169 (delta 102), reused 138 (delta 78), pack-reused 0
    Receiving objects: 100% (169/169), 23.59 KiB | 23.59 MiB/s, done.
    Resolving deltas: 100% (102/102), completed with 22 local objects.
    Already up to date.
    
    $ git --git-dir .git describe --dirty --tags --long
    0.8.0rc0-285-g2a7b9f0
    

    I don't know what setuptools_scm could do about this case, but it is annoying. Maybe at least a warning?

    CC @ashwinvis

    opened by paugier 5
  • write_to= in monorepo

    write_to= in monorepo

    Hi. Let's say I have a dir structure like this:

    ├── backend/
    │   ├── src/
    │   │   ├── foo/
    │   ├── setup.cfg
    │   ├── pyproject.toml
    ├── frontend/
    

    So, I have a project named foo, which has a backend and frontend dirs. Backend is python, the package name is foo.

    What I want to do is to use setuptools_scm in my backend app. The problem is, the .git folder is in the project's root, so one dir above backend. To solve this I have to provide a root option to my setuptools_scm configuration:

    [tool.setuptools_scm]
    write_to = "./src/foo/version.py"
    write_to_template = """\
    # coding: utf-8
    # file generated by setuptools_scm
    # don't change, don't track in version control
    __version__ = \"{version}\"
    """
    root = ".."
    

    I use write_to, because I do from foo.version import __version__ to use it in various places (i.e. initializing FastAPI or loggers).

    Now, there's a problem:

      File "/home/dabljues/projects/foo/backend/.tox/.package/lib/python3.10/site-packages/setuptools_scm/__init__.py", line 78, in dump_version
        with open(target, "w") as fp:
    FileNotFoundError: [Errno 2] No such file or directory: '../src/foo/version.py'
    

    When I don't use write_to, then it works, but I won't have a version.py file generated to later import it in code.

    Is there something I am doing wrong? Can I somehow use setuptools_scm like this (meaning with write_to) in a monorepo like above?

    opened by dabljues 1
Releases(v7.1.0)
Owner
Python Packaging Authority
Python Packaging Authority
This is a python helper package for Telebirr H5 Web payment integration helper.

Telebirr This is a python helper package for Telebirr H5 Web payment integration helper. The use case for this interface is payment via web. Third par

null 24 Dec 13, 2022
Python package used on Hardfight projects to make building, testing and deploying easy.

Hardfight Devtools Build, test and deploy Hardfight projects easly ?? What is it Devtools is a Python tool to make building, testing and deploying int

Hardfight 1 Dec 5, 2021
Python-based continuous integration testing framework; your pull requests are more than welcome!

Buildbot The Continuous Integration Framework Buildbot is based on original work from Brian Warner, and currently maintained by the Botherders. Visit

Buildbot 5k Jan 5, 2023
AWS Tags As A Database is a Python library using AWS Tags as a Key-Value database.

AWS Tags As A Database is a Python library using AWS Tags as a Key-Value database. This database is completely free* ??

Oren Leung 42 Nov 25, 2022
:package: :fire: Python project management. Manage packages: convert between formats, lock, install, resolve, isolate, test, build graph, show outdated, audit. Manage venvs, build package, bump version.

THE PROJECT IS ARCHIVED Forks: https://github.com/orsinium/forks DepHell -- project management for Python. Why it is better than all other tools: Form

DepHell 1.7k Dec 30, 2022
LSO, also known as Linux Swap Operator, is a software with both GUI and terminal versions that you can manage the Swap area for Linux operating systems.

LSO - Linux Swap Operator Türkçe - LSO Nedir? LSO, diğer adıyla Linux Swap Operator Linux işletim sistemleri için Swap alanını yönetebileceğiniz hem G

Eren İnce 4 Feb 9, 2022
Your own movie streaming service. Easy to install, easy to use. Download, manage and watch your favorite movies conveniently from your browser or phone. Install it on your server, access it anywhere and enjoy.

Vigilio Your own movie streaming service. Easy to install, easy to use. Download, manage and watch your favorite movies conveniently from your browser

Tugcan Olgun 141 Jan 6, 2023
Automatically move or copy files based on metadata associated with the files. For example, file your photos based on EXIF metadata or use MP3 tags to file your music files.

Automatically move or copy files based on metadata associated with the files. For example, file your photos based on EXIF metadata or use MP3 tags to file your music files.

Rhet Turnbull 14 Nov 2, 2022
A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

Spack Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, a

Spack 3.1k Dec 31, 2022
A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

Spack Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, a

Spack 3.1k Jan 9, 2023
Xbps-install wrapper written in Python that doesn't care about case sensitiveness and package versions

xbi Xbps-install wrapper written in Python that doesn't care about case sensitiveness and package versions. Description This Python script can be easi

Emanuele Sabato 5 Apr 11, 2022
PyPIContents is an application that generates a Module Index from the Python Package Index (PyPI) and also from various versions of the Python Standard Library.

PyPIContents is an application that generates a Module Index from the Python Package Index (PyPI) and also from various versions of the Python Standar

Collage Labs 10 Nov 19, 2022
QuakeLabeler is a Python package to create and manage your seismic training data, processes, and visualization in a single place — so you can focus on building the next big thing.

QuakeLabeler Quake Labeler was born from the need for seismologists and developers who are not AI specialists to easily, quickly, and independently bu

Hao Mai 15 Nov 4, 2022
Library to manage your own custom RPC on your desktop

Info I don't recommend novices setting this up yourself. It requires Redis, a server to host the API on, and a bit of understanding of Windows & Pytho

Isaac K 1 Apr 16, 2022
nicfit 425 Jan 1, 2023
scrapes medias, likes, followers, tags and all metadata. Inspired by instagram-php-scraper,bot

instagram_scraper This is a minimalistic Instagram scraper written in Python. It can fetch media, accounts, videos, comments etc. `Comment` and `Like`

sirjoe 2.5k Nov 16, 2022
Knowledge Management for Humans using Machine Learning & Tags

HyperTag helps humans intuitively express how they think about their files using tags and machine learning. Represent how you think using tags. Find what you look for using semantic search for your text documents (yes, even PDF's) and images.

Ravn Tech, Inc. 166 Jan 7, 2023
Knowledge Management for Humans using Machine Learning & Tags

HyperTag HyperTag helps humans intuitively express how they think about their files using tags and machine learning.

Ravn Tech, Inc. 165 Nov 4, 2022
document organizer with tags and full-text-search, in a simple and clean sqlite3 schema

document organizer with tags and full-text-search, in a simple and clean sqlite3 schema

Manos Pitsidianakis 152 Oct 29, 2022
Link aggregator community organised by tags in python3/django3 + sqlite3.

sic Link aggregator community organised by tags in python3/django3 + sqlite3. Public instance at https://sic.pm and Tor hidden service.

Manos Pitsidianakis 97 Dec 30, 2022