Packages with dot no longer install(?)

[ghost]

It appears pypiserver is affected by this issue: pypa/pip#3666

At least I can't install my project anymore with the latest pip, and I have dots in all package names.. (pip complains about no such package/no distributions being found)

[sbrandtb]

I'm running into this issue, too. I tested the version from master. It's fixed there, but painfully slow

[dpkp]

We've deployed the 503 patch internally (PR 140 / master) to general success. Do you have any details on the slowdown you are seeing?

[sbrandtb]

We decided to switch to devpi internally because we need pypi-caching, so no chance to check why the version from master was hanging. Probably some DSN lookup or other timeout?

Still, keep up the good work. Pypi-server served us for two years without issues :) Still, I would recommend releasing the latest master because this bug is a critical issue here and probably also in other environments.

[ankostis]

Indeed we have to bake a new release the soonest.

[dpkp]

Try adding --trusted-host <your pypiserver IP/hostname> to pip install.
This is required by pip >=8 when not using https
On Jun 17, 2016 7:26 AM, "Jonas Thiem" notifications@github.com wrote:

This still seems to be broken for me even with latest git master cloned
from today (pypiserver version reported as 1.2.0.dev1)

pip3 install --extra-index http://172.17.0.1:8765/ daphnetf.charon
Downloading/unpacking daphnetf.charonhttp://172.17.0.1:8765/daphnetf.charon/ uses an insecure transport scheme (http). Consider using https if 172.17.0.1:8765 has it available
Could not find a version that satisfies the requirement daphnetf.charon (from versions: 16.4.0.dev0)
Cleaning up...
No distributions matching the version for daphnetf.charon
Storing debug log for failure in /root/.pip/pip.log

... with the package in question definitely being in the package dir of
pypiserver:
['daphnetf.charon-16.4.0.dev0.tar.gz', 'daphnetf.hermes-0.0.1.tar.gz',
'daphnetf.gaia-0.0.1.tar.gz']

However, pip also removed the --allow-external in the same fateful update
that broke pypiserver for me, so I don't even know if my pip arguments are
still supposed to be working like that. Any help would be greatly
appreciated, because I find pip documentation on how to install from
external sources to be notoriously bad... (which hasn't gotten better by
half of the internet examples which used --allow-external now being no
longer working as before)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#139 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAzetP94ZzD2TnNh35d1hnm3JgpI2xzUks5qMq6NgaJpZM4IeD4N
.

[ankostis]

@sbrandtb can you check again if problem persists on the just-released pypiserver-1.2.0.dev1?
(use --pre to pip-install it).

[ankostis]

@sbrandtb Can you confirm if the freshly-released v1.2.0 solves indeed the problem?

[sbrandtb]

@ankostis Sorry, I thought I did answer: No, I cannot because we stopped using pypiserver and I cannot find spare time to test it, sorry.

[ghost]

@ankostis I can confirm it works for me now. I used --trusted-host as required in my pip command, and now it installs just fine with the latest pypiserver github master (with a dot in the package name as before).

[ankostis]

Great, thanks!
Can close now.