| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- setup.py: List useful links using `project_urls`
- setup.py: Specify minumum python vresion using `python_requires`
`python_requires` is the new way of specifying requirements for python
version, as documented @
https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires.
This will also make this requirement appear nicely on the PyPI project
page.
- setup.py: Add project classifiers
PyPI will use these classifiers to categorize projects while searching
or browsing. Full list of classifiers can be found at
https://pypi.org/classifiers.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Buildstream uses the Terminal.does_styling attribute, which was only
added in blessings 1.6.
Blessings helpfully returns an empty string when calling an nonexistent
attribute on the Terminal object, instead of failing.
Because Fedora has blessings 1.5, Buildstream thought that my terminal
couldn't handle styling, and just didn't print the status bar, silently.
Specifying the minimum version avoids this silent failure.
|
|
|
|
|
|
|
| |
Fill out those fields in `setup.py` that are required for publishing a
package on PyPi.
Part of https://gitlab.com/BuildStream/buildstream/issues/587.
|
|
|
|
|
|
|
| |
This allows to use version 0.15.51 rather than 0.15.0 which is
required for Python 3.
Fixes #571.
|
|
|
|
|
| |
This also fixes an error with pylint in setup.py:
setup.py:226:19: R1718: Consider using a set comprehension (consider-using-set-comprehension)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, such as when working inside a virtual environment, it can
be desirable to install all dependencies for running tests using `pip`.
This is currently not possible since setuptools does not support
installing these dependencies in a virtual environment (by design).
(See https://stackoverflow.com/a/21003259.)
To circumvent this issue, move such requirements to
`dev-requirements.txt` file that can be used easily with
`pip install -r`. This also enables tests to be run directly using
`pytest`, which can be more convenient than `-addopts` approach when one
needs to add multiple options.
This will also be useful in creating better testuite images, and fix
some of the issues noticed in
https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/56.
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4f168b9b6a02216e2fae24d758ae6b778e545869.
The latest version of pytest_pylint works fine with pylint 2, which
means there is no longer a reason to restrict the pylint version.
pylint 2 is required for Python 3.7.
|
|
|
|
|
|
| |
This causes the new artifact tests to pass (unless you happened
to already have a recent enough version of pytest-cov, in which case
you didn't notice the breakage).
|
| |
|
|
|
|
|
|
| |
No longer used.
Fixes #134, #138, #148, #217, #268, #276, #443, #460.
|
| |
|
|
|
|
| |
This allows code generation with ./setup.py build_grpc
|
|
|
|
|
|
|
|
|
|
|
|
| |
pylint >2 is not compatible with pytest_pylint in its current form. As
such, allowing any version of pylint for testing results in a failure.
This commit restricts down the allowable versions of pylint to those
that are both compatible with pytest_pylint, and also offer the feature
set that we require.
See https://gitlab.com/BuildStream/buildstream/issues/427 for further
details.
|
|
|
|
| |
As recommended by Valentin David in issue #332.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using setuptools_scm had a couple of bad problems:
o Unexpected versioning semantics, setuptools_scm would
increment the micro version by itself in the case that
we derive a version number from something that is not a tag,
making the assumption that we are "leading up to" the next
micro version.
People mostly dont expect this.
o When installing in developer mode, i.e. with `pip3 install --user -e .`,
then we were always picking the generated version at install time
and never again dynamically resolving it.
Many of our users install this way and update through git, so it's
important that we report more precise versions all the time.
This commit needs to make a series of changes at the same time:
o Adds versioneer.py to the toplevel, this is used by setup.py
for various activities.
This is modified only to inform the linter to skip
o Adds buildstream/_version.py, which is generated by versioneer
and gives us the machinery to automatically derive the correct version
This is modified only to inform the linter to skip
o Adds a .gitattributes file which informs git to substitute
the buildstream/_version.py file, this is just to ensure that
the versioning output would work if ever we used `git archive`
to release a tarball.
o Modifies setup.py and setup.cfg for versioneer
o Modifies utils.py and _frontend/cli.py such as to avoid importing
the derived version when running bash completion mode, we dont
derive the version at completion time because this can result
in running a subprocess (when running in developer install mode)
and is an undesirable overhead.
o Updates tests/frontend/version.py to expect changed version output
|
|
|
|
|
| |
The required version is 0.1.2 based on the fact that we're using
--hostname and --remount-ro.
|
|
|
|
| |
catching-non-exception warnings
|
| |
|
| |
|
|
|
|
|
|
| |
jinja2 2.10 import time has been divided by two compared to Jinja 2.9.6
Fixes #194
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most of the usages of pkg_resources from the codebase, helping
the goal of getting rid of that completely.
With this change, version number is generated during install and embedded into
`__version__` which is then imported by root level `__init__`. From there,
it is used by other parts of the codebase when needed.
Generated `__version__` file is ignored and not tracked by git to prevent
unnecessary 'changes' messages and accidental commits of that file.
|
|
|
|
|
|
|
| |
This change monkey patches setuptools' code generation functionality, so
that pkg_resources won't be imported in the generated file.
Fixes #172
|
| |
|
| |
|
|
|
|
|
|
| |
Our problem is with 4.4.2; and 4.2 lacks some features
and fails to collect all of the coverage from sub processes,
causing our reports to drop by 10%.
|
|
|
|
|
|
| |
This allows running tests in parallel:
./setup.py test --addopts "-n auto"
|
|
|
|
|
|
|
| |
Seeing random crashes with 4.4.2, these are solved by
simply using version 4.2.
Need to investigate and report proper bug to upstream for this.
|
| |
|
|
|
|
|
| |
Fixes the previous commits which attempt to allow optionally
only installing bst-artifact-receive, which doesnt work, because pip.
|
|
|
|
|
|
| |
A convenience to install `bst-artifact-receive` on an artifact server
that does not have the ostree and bubblewrap requirements to install
the main `bst` program.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The upstream of fuse.py is <https://github.com/terencehonles/fusepy>. It looks
pretty abandoned -- there have been no commits there since 5th April 2016 and
there are 17 pull requests dating from 2013 onwards that are still waiting for
responses from the maintainer.
There's no support in fuse.py for ppc64 platforms which means BuildStream is
unusable on that architecture at present. My pull request to fix that upstream
is being ignored; since the module is a single .py file provided under the
ISC license it is simplest to pull the whole thing into buildstream.git instead.
The version of fuse.py that's been embedded is the one from pull request #72,
from upstream release v2.0.4 (commit 0eafeb5).
|
|
|
|
|
|
|
|
| |
A previous change introduced the usage of pytest.param to our test
suite in commit 7aba0bfc906409073c4d246ec009a8622551726a.
This was only added to pytest 3.1.0, and the tests can't work with older
versions.
|
|
|
|
| |
Turns out we do need this in some corner cases
|
|
|
|
|
|
|
| |
Turns out this doesnt work once you try to actually
run the full buildstream in a test case (in foreground
it screws with other parsing, in background it fails
in the test context with a strange error).
|
|
|
|
|
| |
Currently this gets installed at ${prefix}/share/bash-completion/completions
but this is not exactly correct.
|
|
|
|
| |
Fixes #58
|
| |
|
|
|
|
| |
Added entry point for running `bst-artifact-receive`
|
|
|
|
| |
Including changes in _site.py and setup.py
|
| |
|
| |
|
| |
|
|
|
|
| |
We can start using those to assert the version >= 2017.4
|
| |
|
|
|
|
| |
Now you can only invoke BuildStream with the `bst` command
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This plugin automatically encodes git versioning information
into the package version string so that it shows up in `bst --version`
This versioning information is encoded into source distributions
as well, so that when installing from a source distribution without
the git repository the precise VCS provenance is still encoded into
the version.
|