The entry_point option already defines the /bin/swift script implicitly.
The definition of `scripts=bin/swift` ontop of that leads to a corrupt wheel build and can lead to a collision error during installation:
FileExistsError: File already exists: [...]/bin/swift
Closes-Bug: #1996959
Change-Id: I17d0c2b02555172eeedaa164aad956691ccb3b0a
Include project_urls so PyPI gets more sidebar links.
Include long_description_content_type to quiet a twine warning.
Change-Id: Id3b90927ba24fd47efdbeeb2107bdae9e86e93ba
There's a lot of cleanup possible, but this is a start.
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change-Id: Ia1176b7fd5434d52070d482a37abfbb98800cdb3
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: Ief2c7a217914dc5cacdffc6959ed0585fc6a1225
Update docs building:
* Switch to sphinx-build
* Update requirements for Sphinx and openstackdocstheme for
python 3
* Remove unneeded doc and translation sections from setup.cfg
* Remove install_command, it's unneeded, the default is fine.
Change-Id: Ib9fe754b700bceb164ba0f596cbcc6d864ccbadc
I'm giving up on trying to back out all of the test-requirements
up-revs, but let's try to stay compatibile with old requests/six.
As part of that, only disable some requests warnings on new-enough requests.
Note that we should now be compatible with distro packages back to
Ubuntu 16.04 and CentOS 6. Our six is still too new for Trusty, but
hey, there's less than a year left on that anyway, right?
Change-Id: Iccb23638393616f9ec3da660dd5e39ea4ea94220
Related-Change: I2a8f465c8b08370517cbec857933b08fca94ca38
Create a tox environment for running the unit tests against the lower
bounds of the dependencies.
Create a lower-constraints.txt to be used to enforce the lower bounds
in those tests.
Add openstack-tox-lower-constraints job to the zuul configuration.
Update the dependencies needed to make the unit tests pass while
constrained to the lower bounds.
See http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html
for more details.
Co-Authored-By: Nguyen Hai <nguyentrihai93@gmail.com>
Change-Id: I2a8f465c8b08370517cbec857933b08fca94ca38
Depends-On: https://review.openstack.org/555034
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This lets us use Keystone sessions against endpoints like swauth and
tempauth with code like:
import keystoneauth1.loading
import keystoneauth1.session
import swiftclient
loader = keystoneauth1.loading.get_plugin_loader('v1password')
auth_plugin = loader.load_from_options(
auth_url='http://saio:8080/auth/v1.0',
username='test:tester',
password='testing')
keystone_session = keystoneauth1.session.Session(auth_plugin)
conn = swiftclient.Connection(session=keystone_session)
The plugin includes an optional project_name option, which may be used
to override the swift account from the storage url that was returned.
Additionally, it includes enough infrastructure to support some commands
in python-openstackclient>=3.0:
export OS_AUTH_TYPE=v1password
export OS_AUTH_URL=http://saio:8080/auth/v1.0
export OS_PROJECT_NAME=AUTH_test2
export OS_USERNAME=test:tester
export OS_PASSWORD=testing
openstack token issue
openstack catalog list
openstack catalog show object-store
openstack object store account show
openstack container list
openstack container create <container>
openstack container save <container>
openstack container show <container>
openstack container delete <container>
openstack object list <container>
openstack object create <container> <file>
openstack object save <container> <object>
opsentack object show <container> <object>
openstack object delete <container> <object>
Change-Id: Ia963dc44415f72a6518227e86d9528a987e07491
"Python 3.3 support is being dropped since OpenStack Liberty."
written in following URL.
https://wiki.openstack.org/wiki/Python3
And already the infra team and the oslo team are dropping py33
support from their projects.
Since we rely on oslo for a lot of our work, and depend on infra
for our CI, we should drop py33 support too.
Change-Id: Ia8f2b26e446175b0d892a11952ef3dc11dcdc73c
Closes-Bug: #1526170
As of mitaka, the infra team won't have the resources available to
reasonably test py26, also the oslo team is dropping py26 support
from their libraries. sine we rely on oslo for a lot of our work,
and depend on infra for our CI, we should drop py26 support too.
Closes-Bug: 1519510
Depends-On: I37116731db11449d0c374a6a83a3a43789a19d5f
Change-Id: I776847ce77dfe82880f34d0b7804514e5aed3f8d
A Swift client executable needs to be provided on Windows since Python scripts
cannot be executed directly.
This approach is also consistent with other OpenStack Python clients (e.g.
Nova, Neutron, Cinder, etc.).
Change-Id: I7f03b7c305dceed4fa6f4fe1c1281659820606e4
Closes-Bug: #1359360
Note that this should not land until we figure out why `tox -e py33` doesn't
actually run any tests.
Change-Id: Id4e080cfbfca45b3bf7ed81b03a31414495a1348
To make bin/swift importable for testing it needs to be renamed/moved.
The final idea is to move it to swiftclient/shell.py and add only a stub
in bin/swift to import swiftclient/shell.py.
However, doing this in a single step makes reviewing very hard, because
now there are > 1400 lines deleted from bin/swift and added to
swiftclient/shell.py - Gerrit doesn't detect the moved file.
For example: https://review.openstack.org/#/c/73710/2/
This patch first moves the code to swiftclient/shell.py and uses
setup.py/cfg to create the stub file in bin/swift. A follow up
(https://review.openstack.org/#/c/76489/) will then add the stub itself
in bin/swift (and remove the entry in setup.py).
The change to tox.ini is related to bug 1290562 and can be removed in
the future.
Change-Id: Id86392ccaf09e1d80a5d808fb49827d6d18c2588
According to FHS 2.3 the correct place to install the manpage for a
binary in /usr/local/bin/ would be /usr/local/man/.
However, on Debian/Ubuntu-based systems /usr/local/man/ is a link to
/usr/local/share/man/ and on other systems /usr/local/man/ might not
exist at all.
Even worse, if the client is installed in /usr/bin/ the manpage
should should be installed in /usr/share/man, but will be installed
in /usr/man/ which is completely wrong.
This patch fixes this and uses share/man/man1 as common prefix. Doing
this will install the manpage either in /usr/local/share/man/man1 or
/usr/share/man/man1.
Partial-Bug: 1269715
Change-Id: I590932f00476eacd434cdae012fd62010845581d
Currently the existing manpage isn't copied to /usr/local/man/man1
when installing swiftclient from source. This patch fixes this.
Change-Id: Ib2ee091d5e1d4c37a4e5a00f50fa19df44bd3c41
Partial-Bug: 1269715
nose is invasive and can sometimes alter the outcome of a test run. testr,
on the other hand, keeps a distinction between running tests and displaying
results of the test runs. Additionally, it supports the stock python unittest
protocol.
Even better, testr supports parallel test running, which makes things faster,
and a command "testr run --failing" which will just re-run the latest failing
tests (often something one wants to do in iterative dev)
Part of blueprint grizzly-testtools
Change-Id: I0b3f1bcb5d4ff59c65eb3219b30a9e64f54d70bd
To better facilitate the building and publishing of sphinx
documentation by Jenkins we are moving all openstack projects with
sphinx documentation to a common doc tree structure. Documentation
goes in project/doc/source and build results go in project/doc/build.
Change-Id: Ibe6745cac73817ea06faca77367b4269d5137a24
DavHau