Apologies for this being last minute, but I'm currently attending the PyConAU dev sprints taking place today and tomorrow, 05Aug-06Aug UTC+10.
I plan on working on the following:
* My existing PR for the ldap auth plugin (https://github.com/devpi/devpi-ldap/pull/43), it needs refinement.
* Adding info on bootstrapping an LDAP server.
* Adding contributing information to the documentation.
If there's time, I'm might try cherry-picking a few other things from the issues list.
I'll be lurking in the devpi IRC channel throughout the event. I might be able to wrangle some other to assist as well.
I created a PR for a new request events hook at
The problem with the current hooks devpiserver_stage_created,
devpiserver_on_changed_versiondata and devpiserver_on_upload is that
they are database events. That means when data is imported or
replicated, they are called again. That is also why they don't have
access to the request and thus infos like the logged in user. The
devpiserver_on_upload_sync is called from within the request, but it may
be called prematurely, because the current transaction wasn't commited
and there could be an error. There is also a possible race condition due
to that, because the file may not be accessible when the triggered
plugin does something. Again the infos the hook currently gets is
limited as well.
In the proposed implementation the event handlers are called after the
data was sent to the client. This was done to ensure a plugin won't
block normal operation. The client always gets the result of the request
first. The downside is that when the client needs a long time to fetch
the response, the event handlers are delayed. It might be useful to call
the handlers in a separate thread while the client is served. Comments
on this are welcome. For now I wanted to avoid the added complexity.
Another change from the old hooks is, that it is possible an event
handler isn't called. This only happens when devpi-server is stopped
after commit, but before the event handlers were called. I consider this
a minor issue, but again, comments on this are welcome.
Thank you for the project, quick question:
I see that restrict-modify actually only allows changes made by the principals listed there. Which kinda means that you are either root or you aren't, should restrict-modify also allow index_create/user_modify for authenticated users?
Hello Devpi deverlopers,
We're looking for a solution for internal PyPi server.
We like developers/data Scientists to use the packages only from the
internal repo, which is approved by legal and scanned for
security purposes. Can we let admins to download from external PyPi, and
other users only download from internal repo only? If the package is not in
the local repo, the developers need to discuss with Admin first.
From reading the doc it seems Devpi can be a through cache. Is this
something Devpi can do?
Thank you very much!
I am having the exact same issue. I've set up devpi to be served inside a
kubernetes cluster and use "edge-termination" for SSL traffic.
This means that the traffic goes from the browser to K8S as HTTPS which
forwards the traffic *unencrypted* to devpi. All links to resources like
CSS and JS files are rendered as "http" on the returned document which
causes the browser to block them.
On a wild guess I assume that devpi auto-detects the protocol? If that is
the case then is makes sense that the links are generated as HTTP instead
of HTTPS. Because the edge-termination of SSL traffic makes devpi
blissfully unaware that there is SSL in place.
So there would need to be a way to force devpi to generate links as HTTPS
instead of HTTP. Is there a way to do this?
A heads up for the changes in upcoming major releases of devpi-client
Deprecations and Removals
- removed deprecated "quickstart" command.
- decoupled the functional tests from devpi-server and run devpi-server
in a Python 3 virtualenv when testing with Python 2.7.
- The selection of the Python interpreter used for ``devpi upload`` has
changed. If used the new ``-p/--python`` option has priority, then a
currently activated virtualenv, lastly the ``sys.executable`` under
which devpi is running.
Deprecations and Removals
- fix #518: There are no URLs on PyPI anymore that need to be scraped or
crawled, so the code for that was removed.
- removed support for long deprecated ``acl_upload`` and ``bases``
mirror index option. They were only kept for compatibility with
devpi-client <= 2.4.1.
- removed long deprecated ``pypi_whitelist`` index option. It was only
kept for compatibility with devpi-client <= 2.4.1.
- deprecated Python 2.7 support. This is the last major version
supporting Python 2.7. For upgrading to Python 3.x you have to export
your data using your current setup with Python 2.7 and import it in a
new installation with Python 3.x.
- major releases don't require an export/import cycle anymore except
when explicitly announced. You should always make a backup though! When
upgrading to devpi-server 5.0.0 you can keep the state as is and even
downgrade to the last 4.9.x release if necessary. Don't forget to backup
- the --storage option is now required when a storage plugin like
devpi-postgresql is in use. It's recommended to use a configuration file
for devpi-server to have everything in one place.
My name is Alfons, and I am interested in the devpi server. We would like
to install it permanently in a remote server, but we have problems with the
server configuration. Our problem is that we can not connect with the
server, the response is always "connection refused". We are using a Linux
server with Apache, and we check it, and we don't have any firewall
configured. Also, we have configured the allowed host as 0.0.0.0 to accept
May you could help us to configure it, our give us some advisor. We
understood that is not necessary to use the nginx, but is necessary to use
supervisor? Do you know another tutorial or detailed guide?
Thank you for your time,