| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
For details on the new PyPI, see the blog post:
https://pythoninsider.blogspot.ca/2018/04/new-pypi-launched-legacy-pypi-shutting.html
|
| |\ |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Helps pip decide what version of the library to install.
https://packaging.python.org/tutorials/distributing-packages/#python-requires
> If your project only runs on certain Python versions, setting the
> python_requires argument to the appropriate PEP 440 version specifier
> string will prevent pip from installing the project on other Python
> versions.
https://setuptools.readthedocs.io/en/latest/setuptools.html#new-and-changed-setup-keywords
> python_requires
>
> A string corresponding to a version specifier (as defined in PEP 440)
> for the Python version, used to specify the Requires-Python defined in
> PEP 345.
|
| |\ \
| |/ |
|
| | | |
|
| |/ |
|
| |\
| |
| | |
Use flake8-import-order
|
| | |\ |
|
| | | | |
|
| | |/
|/| |
|
| |/
|
|
|
|
|
|
| |
We don't want to install this as a system plugin. Now that flake8 3.5.0
is in the wild, we can use this.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: #4492
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We're going to be adding additional badges to this but, before we do
that, we should improve the README and remove a lot of the duplication
that has built up here.
The 'long_description' from 'setup.py' is moved into the README as there
is serious value in displaying this on GitHub, as much as there is value
in including the badges and other content from README.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
|
|
|
|
| |
We are using this in our testing and actually need it for the flake8
plugin, so include this in the list of 'test' requirements.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
|
|
|
|
|
|
|
|
| |
'mock' is part of the standard library in Python 3 since Python 3.3.
However, it's found in 'unittest.mock' - not 'mock'. We should install
the version for PyPi in all cases to minimize differences between the
two. When Python 2.7 support is dropped, we can consider switching to
the standard library version.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes #4284
|
| |\
| |
| | |
The great toxification (part 4)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Simply installing packages will ensure that most of the dependencies in
'setup.py' are installed, meaning 'test-reqs.txt' need only contain
those necessary for testing.
The only notable change is that the 'simplejson' module is dropped from
the requirements list. This included as a dependency for the PyPy
target, but it appears that this is not necessary today (though it may
have been when the target was added in 2011).
This retains 'setup.py test' which, as noted in the tox docs [1], is
sometimes expected for downstream distribution testing. We may wish to
find a way to synchronize requirements between 'test-reqs.txt' and this
section in the future, but that's work for another day.
[1] https://tox.readthedocs.io/en/latest/example/basic.html#integration-with-setup-py-test-command
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| | |
| |
| |
| |
| |
| |
| | |
This version is silly old and anyone that's _still_ using this is not
going to be building Sphinx from source. Simply remove it.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If we want to check style, we run 'tox -e flake8': it shouldn't be
necessary to run some obscure 'make' command too. Make this possible by
moving the sole useful test from the target of this make command to a
flake8 plugin.
This includes a fix for a header that was previously excluded from
checks, but is now included.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're going to move the executable's here (or at least those that part
of the core library). The 'sphinx-build' executable was already moved,
so lets do 'sphinx-quickstart' next.
To avoid breaking packages that are using this feature directly, aliases
for the old 'main' method are included. This is based on what Django
does [1] and, like Django, will allow us to safely remove the old
modules in Sphinx 2.0.
[1] https://github.com/django/django/blob/1.11/django/test/runner.py#L688-L695
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have multiple executables in tree and, while 'sphinx-build' is
arguably the most important of these, there's no reason its importance
should warrant inclusion at the package level.
Create a new module, 'sphinx.cmd', and move the code from
'sphinx.__init__' into a 'build' submodule within. This name might be a
bit disingenuous at present, given the availability of 'make-mode' here
too, but that's an artifact of the current executable design and can be
cleaned up later.
To avoid breaking packages that are using this feature directly, aliases
for the old 'main' method are included. This is based on what Django
does [1] and, like Django, will allow us to safely remove the old
modules in Sphinx 2.0.
[1] https://github.com/django/django/blob/1.11/django/test/runner.py#L688-L695
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'sphinx-apidoc' tool is no longer the only kid on the block when it
comes to automatic documentation of Python projects, with the likes of
'sphinx-autoapi' in development [1], and is not really maintained. Given
the fact that the tool is tangential to Sphinx's main goal, there isn't
really anything that warrants its continue existence as a core module.
Signify this by moving the feature to 'ext'. This allows the feature to
continue to exist in the package, but indicates that stability might be
worse than one would expect from the core library.
To avoid breaking packages that are using this feature directly, such as
pbr [3], aliases for the old 'main' method are included. This is based
on what Django does and, like Django, will allow us to safely remove the
old modules in Sphinx 2.0.
[1] https://github.com/rtfd/sphinx-autoapi
[2] https://github.com/sphinx-doc/sphinx/pull/3485#issuecomment-288081223
[3] https://github.com/django/django/blob/1.11/django/test/runner.py#L688-L695
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
pkg_resources.DistributionNotFound: The 'typing' distribution was not found and is required by Sphinx
|
| |/
|
|
| |
pkg_resources.DistributionNotFound: The 'typing' distribution was not found and is required by Sphinx
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
