Updates the Docker configuration to use the gunicorn server with gevent
workers by default. Adds `waitress` to the docker container, so that if
no server is specified, we will fall back to that rather than `wsgiref`.
Making this happen brought a few other issues to light, which are also
addressed here.
- Docker log output not immediately being flushed to stdout (#358):
resolved by setting the `PYTHONUNBUFFERED` env var to `t` in the
docker container
- When the WSGIRef server is selected, its access logs are written
directly to stderr, rather than going through the logging machinery:
resolved by adding a new `WsgiHandler` class and passing in to
bottle's `run()` method when running the wsgi server. This required a
new `ServerCheck` class to determine whether the wsgi server is
selected when the `auto` option is used
- When using `gunicorn` along with the watchdog cache, package uplaods
were not being picked up by the watcher. Updated the `add_package`
and `remove_package` methods on the `CachingFileBackend` to bust the
cache
* Docker improvements
This addresses much of what was brought up in #359. Specifically, it:
- Significantly improves testing for the Docker image, adding a
`docker/test_docker.py` file using the regular pytest machinery to
set up and run docker images for testing
- Hopefully addresses a variety of permissions issues, by being explicit
about what access pypiserver needs and asking for it, only erroring
if that access is not available
- Requires RX permissions on `/data` (R to read files, X to list files
and to be able to cd into the directory. This is important since
`/data` is the `WORKDIR`)
- Requires RWX permissions on `/data/packages`, so that we can list
packages, write packages, and read packages.
- When running in the default configuration (as root on Linux or
as the pypiserver-named rootish user on Mac), with no volumes
mounted, these requirements are all satisfied
- Volume mounts still must be readable by the pypiserver user (UID
9898) in order for the container to run. However, we now error early
if this is not the case, and direct users to a useful issue.
- If the container is run as a non-root, non-pypiserver user (e.g.
because someone ran `docker run --user=<user_id>`, we try to run
pypiserver as that user). Provided that user has access to the
necessary directories, it should run fine.
- Fixes issues with running help and similar commands
- Updates the Docker image to use `PYPISERVER_PORT` for port
specification, while still falling back to `PORT` for backwards
compatibility
- Moves some docker-related things into a `/docker` directory
- Adds a `Makefile` for building a test fixture package sdist and wheel,
so that test code can call `make mypkg` and not need to worry about it
potentially building multiple times
The only issue #359 raises that's not addressed here is the one of
running pypiserver in the Docker container using some non-default server
for performance. I would like to do some benchmarking before deciding on
what to do there.
Following the discussion in #253 and #325 I've created a first iteration on what a `Backend` interface could look like and how the current file storage operations may be refactored into this interface. It goes from the following principles
* `app.py` talks only to `core.py` with regards to package operations
* at configuration time, a `Backend` implementation is chosen and created for the lifetime of the configured app
* `core.py` proxies requests for packages to this `Backend()`
* The `Backend` interface/api is defined through three things
* methods that an implementation must implement
* methods that an implementation may override if it knows better than the defaults
* the `PkgFIle` class that is (should be) the main carrier of data
* where possible, implementation details must be hidden from concrete `Backend`s to promote extensibility
Other things I've done in this PR:
* I've tried to talk about packages and projects, rather than files and prefixes, since these are the domain terms PEP503 uses, and imho it's also more clear what it means
* Better testability of the `CacheManager` (no more race conditions when `watchdog` is installed during testing)
* Cleanup some more Python 2 code
* Started moving away from `os.path` and `py.path` in favour of `pathlib`
Furthermore I've created a `plugin.py` with a sample of how I think plugin system could look like. This sampIe assumes we use `argparse` and allows for the extension of cli arguments that a plugin may need. I think the actual implementation of such a plugin system is beyond the scope of this PR, but I've used it as a target for the Backend refactoring. If requested, I'll remove it from this PR.
The following things still need to be done / discussed. These can be part of this PR or moved into their own, separate PRs
- [ ] Simplify the `PgkFile` class. It currently consists of a number of attributes that don't necessarily belong with it, and not all attributes are aptly named (imho). I would like to minimalize the scope of `PkgFile` so that its only concern is being a data carrier between the app and the backends, and make its use more clear.
- [ ] Add a `PkgFile.metadata` that backend implementations may use to store custom data for packages. For example the current `PkgFile.root` attribute is an implementation detail of the filestorage backends, and other Backend implementations should not be bothered by it.
- [ ] Use `pathlib` wherever possible. This may also result in less attributes for `PkgFile`, since some things may be just contained in a single `Path` object, instead of multtiple strings.
- [ ] Improve testing of the `CacheManager`.
----
* move some functions around in preparation for backend module
* rename pkg_utils to pkg_helpers to prevent confusion with stdlib pkgutil
* further implement the current filestorage as simple file backend
* rename prefix to project, since that's more descriptive
* add digester func as attribute to pkgfile
* WIP caching backend
* WIP make cache better testable
* better testability of cache
* WIP file backends as plugin
* fix typos, run black
* Apply suggestions from code review
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
* add more type hints to pass mypy, fix tox.ini
* add package count method to backend
* add package count method to backend
* minor changes
* bugfix when checking invalid whl file
* check for existing package recursively, bugfix, some more pathlib
* fix unittest
* rm dead code
* exclude bottle.py from coverage
* fix merge mistakes
* fix tab indentation
* backend as a cli argument
* fix cli, add tests
* fix mypy
* fix more silly mistakes
* process feedback
* remove dead code
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
I gave test_server.py some much needed attention. This file now take ~30 seconds on my machine to run (down from 130 seconds), and I cleaned up the code a little. Let's see how this goes in CI
Commits:
-------------
* minimize time.sleep, convert to pathlib
* refactor, dry code
* run black
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
This PR is a pretty substantial refactor of the entrypoints of pypiserver (`__main__` and `__init__`) to use the argparse-based config added in #339.
- Updated `RunConfig` and `UpdateConfig` classes to have exclusive init kwargs, instead of taking an namespace. This turned out to be much easier when working with the library-style app initialization in `__init__`, both for direct instantiation and via paste config
- Added an `iter_packages()` method to the `RunConfig` to iterate over packages specified by the configuration (note @elfjes, I think that replacing this with e.g. a `backend` reference will be a nice way to tie in #348)
- Added a general-purpose method to map legacy keyword arguments to the `app()` and `paste_app_factory()` functions to updated forms
- Refactored the `paste_app_factory()` to not mutate the incoming dictionary
- Removed all argument-parsing and config-related code from `__main__` and `core`
- Moved `_logwrite` from `__init__` to `__main__`, since that was the only place it was being used after the updates to `core`
- Updated `digest_file` to use `hashlib.new(algo)` instead of `getattr(hashlib, algo)`, because the former supports more algorithms
- Updated `setup.py` to, instead of calling `eval()` on the entirety of `__init__`, to instead just evaluate the line that defines the version
- Assigned the config to a `._pypiserver_config` attribute on the `Bottle` instance to reduce hacky test workarounds
- Fixed the tox config, which I broke in #339
* Config: add auth & absolute path resolution
* Config: check pkg dirs on config creation
* Instantiate config with kwargs, not namespace
* WIP: still pulling the threads
* Init seems to be working
* tests passing locally, still need to update cache
* Fix tox command
* unused import
* Fix typing
* Be more selective in exec() in setup.py
* Require accurate casing for hash algos
* Remove old comment
* Comments, minor updates and simplifications
* move _logwrite to a more reasonable place
* Update config to work with cache
* Type cachemanager listdir in core
* Update config module docstring, rename method
* Add more comments re: paste config
* Add comments to main, remove unneded check
* Remove commented code
* Use {posargs} instead of [] for clarity in tox
* Add dupe check for kwarg updater
* Remove unused references on app instance
* Fix typo
* Remove redundancy in log level parsing
Thanks @elfjes for pointing out that I'd missed this! I also went ahead
and bumped the version in the README to 2.0.0dev1, so that it's clear
that what's in master shouldn't be what people expect from pypi or in the
docker image.
Adds an argparse config that, while adding subcommands (`pypi-server run` and `pypi-server update`), retains full commandline backwards compatibility with the existing config parsing logic.
There's a bit of hackery required to do this, so this also issues a warning if using the non-subcommand arguments, allowing us to potentially remove support for the old form in our next next major version bump (i.e. 3.0).
Also adds a `.pyproject.toml` with a black config, and a mypy config block to `setup.cfg`.
`mypy` is now called in `tox`, currently only for `config.py`, because nothing else typechecks successfully.
----
* WIP: argparse config
* Complete config
* Test all the config options
* Another test and a note re: being unused
* mypy config, call mypy in tox
* No mypy on pypy
* Fix tox config
* Add venv to black ignore
* fix tox config (again)
* Fix formatting, simplify error handling
* FMT: Run black on changed files
* Cleanup setup.py
* remove explicit inheritance from object
* convert most string interpolations to f-strings
Co-authored-by: Pelle Koster <pelle.koster@nginfra.nl>
* run black on codebase
* add black check to travis ci
* add pyproject.toml, revert black on bottle.py
Co-authored-by: Pelle Koster <pelle.koster@nginfra.nl>
* log to stdout
* add stdout logging to config and test it
* remove non-implemented parameter from docs
* configure log stream based on config, somehow this change got lost
* fix unittests for other python versions
* option to specify log stream
* Be more explicit in usage text
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
* remove redundant arguments
* be more consistent in usage text
* add test for disabling stream logging
* fix side-effect of unittests
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
* Add the option to specify list of modules we don't want to update
Signed-off-by: Peter Slovak <peter.slovak@websupport.sk>
* Fix docs
Signed-off-by: Peter Slovak <peter.slovak@websupport.sk>
* Minimize the number of strip() calls
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
* Log an exception when we fail to open/read the package blacklist file
* Abort server startup if we fail to read the blacklist file
Co-authored-by: Matthew Planchard <mplanchard@users.noreply.github.com>
* [268] Ensure remove_pkg removes all pkg instances
Reported by @esciara in #268.
Previously, the `remove_pkg` command was only removing the first
matching package that it found so if, for example, there were a .tar.gz
file and a .whl file, it would only remove one of them.
Of course, it could be run in succession to accomplish full removal, but
the expected behavior is that removal will remove the package entirely.
Here, I've grouped `remove_pkg` related tests into a test class, added
some tests that verify the expected behavior, and updated the
`remove_pkg` method to remove all matching packages.
* CHANGES.rst
Resolves#237
Previously, we were not running any sort of URL escaping on values
passed in from the client that were used for redirects. This allowed
injection attacks via URL encoded newlines in the original request.
This update ensures that all user-supplied paths that are used as
components of redirects are passed through `urllib.parse.quote()`
(or the python 2 equivalent) prior to being used in a redirect
response.
Also specified 127.0.0.1 rather than 0.0.0.0 (the default) in server
tests to avoid triggering firewall dialogs when testing on MacOS
Resolves#226
Cleaned up `test_server.py` a bit:
* Call `twine` via `Popen` instead of using their internal API, which
should help us from having to fix twine tests as often
* Cleaned up fixtures
* Some PEP8 updates and general formatting
* Grouped test fixtures and functions all before the tests themselves
* Refactored `updae()` into several single-responsibility functions
* Added tests for said functions
* Some PEP 008 cleanup
* Imported standard `__future__` imports in `manage.py` and its test
module
Resolves#205 - pypi.python.org shutting down
* Updated the default fallback URL to `pypi.org/simple` rather than
`pypi.python.org/simple`
* Scrubbed references and links to `pypi.python.org`
* Fixed tests breaking due to the removal of `pip.main()` in pip 10.0 -
see pypa/pip#5080 for more info
The ability to propagate configuration values from a paste config
file was introduced in #156. However, as pointed out in #125
by @redbaron4, the string strip method introduced in #156 was
problematic in Python 2.
This resolves that issue while also creating a test that fails
on the current master and passes with updates, demonstrating the
issue.
In addition to including tests from @jameshiebert with slight
updates, I have also resolved an issue with newer versions of twine,
which require an extra parameter in the calls to `upload` and
`register`.
Resolves#179
Due to a pypi API change (reasoning
[here](https://mail.python.org/pipermail/distutils-sig/2017-October/031712.html),
thanks to @natefoo for the link), the redirect links that we were
generating for distributions not present in the package index were
failing with `403` errors.
@ankostis, I have not had time to look into why the standalone tests are
failing. Perhaps we should just ignore them in order to get a new
version out once this is merged to master?
`pypi.python.org/simple` will respond to HTTP requests with `403: SSL is required.`
This will change the default fallback_url to use HTTPS. This should fix#179.
* Updated .travis.yml to fix PEP 440 warnings
* Fixed twine calls
We were getting test failures on multiple branches in
`test_server.py`. I first investigated a warning message
popping up in every test run:
```
PEP440Warning,
/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py:2510: PEP440Warning: 'setuptools (git-0.4.0)' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions.
```
Moving the installation of setuptools, pip, sphinx, and tox
into the `install` key for Travis resolved that issue, but
`test_server.py` tests were still failing. It turns out that
Twine 1.7.0 added support for SSL cert specification and,
in the process, changed the call signature for the `upload`
and `register` internal methods.
This PR fixes the calls so that they align with Twine's new
function signature. Note that tests now fail on Twine <1.7.0,
so I have also updated the dev requirements file.
