--no-install option is deprecated for pip 1.5 about pip-accel

[hvdklauw]

Oh good, they didn't totally screw pip-accel here, they just cleaned the command line API a bit.

Would be nice though if they actually had some pending deprecation period :S

[xolox]

Thanks for reporting this issue. For now I've pinned pip >= 1.4, < 1.5 which takes care of the immediate problem.

I've read through most of pypa/pip#906 but that doesn't leave me with a clear idea of what has already changed and what will change in the near future. It looks like I'll just have to sit down and try to upgrade pip-accel to use pip 1.5 in order to see how much work is involved.

I'll leave this issue open as a reminder to upgrade pip-accel to use pip 1.5.

[graingert]

👍

[jzoldak]

+1 for upgrading pip-accel to be able to use the latest version of pip

[santagada]

What is needed to upgrade to pip 1.5? Or better yet what is necessary to make pip-accel part of pip itself?

[olexiystrashko]

+1 for upgrading pip-accel to be able to use the latest version of pip

[graingert]

The PyPA blessed approach to fast installs is to create a devpi instance
and upload built wheel files for your platform.
On 11 Dec 2014 13:37, "Olexiy Strashko" [email protected] wrote:

+1 for upgrading pip-accel to be able to use the latest version of pip

Reply to this email directly or view it on GitHub
#22 (comment).

[olexiystrashko]

Thanks, Tomas.
Can you recommend a good guide for implementing pip + devpi for fast installs?

[xolox]

@santagada:

What is needed to upgrade to pip 1.5?

What is needed is for me to sit down for a weekend or two and try to upgrade and see how much has changed. Some notes about this:

• One thing that helps a lot is the improved coverage of the pip-accel test suite, this will help me to notice breakage immediately after the upgrade. I also recently finished several refactorings / additional features that I wanted to get out of the way before upgrading to pip 1.5 (the huge internal API refactoring, support for configuration files, pluggable cache backends, etc).
• A somewhat delaying factor is that I personally haven't found a pressing need to upgrade to pip 1.5. This is not to say that I don't want to upgrade, of course I do and will, I just need to find the time (and like everyone I don't have copious amounts of free time unfortunately).

Or better yet what is necessary to make pip-accel part of pip itself?

To be honest I don't see that happening, but maybe that's just me. While I was working on getting pip-accel stable and feature complete, dozens of other people noticed the same problems in the Python ecosystem I was trying to fix with pip-accel and decided to fix them in different ways. Pushing binary wheels to a private devpi instance is one example as @graingert mentioned (it's a lot more heavy weight than pip-accel though, which is why I think pip-accel still has a place in the Python ecosystem).

---

A general question: Do people have a pressing need for features in pip 1.5? (I'm just curious about specific features that people are missing)

[xolox]

A general question: Do people have a pressing need for features in pip 1.5? (I'm just curious about specific features that people are missing)

To clarify the intent behind the question above: If there are pressing reasons to upgrade that can motivate me to do the upgrade earlier. But then I have to know, not guess :-).

[santagada]

No pressing needs, just that I have the latest pip on my system and installing pip-accel in each venv is slow in itself because it has to also downgrade pip.

[xolox]

@santagada: Okay that makes sense, thanks for the feedback. I'll see if I can pick this up soon.

[santagada]

Discovered a major issue, on osx 10.10 and pip 1.4 if i try: pip install ipython it downloads the tar.gz and not the whl file which has two side effects: It is slower to install and the whl correctly depends on a gnureadline library wich osx doesn't have.

[xolox]

@santagada: Please refer to issue #34, I solved this already but we have to be a bit patient for a new release of iPython to be released to PyPI :-). The issue mentions a temporary workaround until a fixed iPython distribution is uploaded.

[xolox]

I'm investigating how much is needed to upgrade pip-accel's pip dependency (and how much hacks and workarounds required for earlier versions of pip I can remove - if I'm going to do this I want to do it right) and I'm leaning towards upgrading straight to pip 6.x. Does anyone see a serious problem with this?

My reasoning: I'm not really looking forward to upgrading to functionality that I already know is marked as deprecated and which will be emitting deprecation warnings, so instead of upgrading to pip 1.5.x I'd rather go straight to pip 6.x. (really 1.6.x but I digress).

[jzoldak]

Hi Peter. +1 for going straight up to the latest.

[rsaftoiu]

+1 for going straight up to the latest as well. This whole project is awesome btw :)

[xolox]

Thanks for all of the feedback on this issue so far and note that I'm definitely hearing all of you loud and clear: pip-accel should be using the latest version of pip! I'm currently working on a feature branch... Some quick-ish notes about that:

1. I'm replacing the usage of --no-install with --download because --no-install is deprecated and will be going the way of the dodo. I'd rather use a supported feature instead...
2. Because of point one and because the pip download cache has been abandoned (they call it deprecated, but properly speaking the feature no longer exists IIUC) I'm forced to change the pip-accel source index into the functional equivalent of pip's download cache: In the old situation the pip-accel source index contained symbolic links pointing into the pip download cache, in the new situation the pip-accel source index contains the archives instead of symbolic links pointing to archives.
3. In my current (unpublished) feature branch all tests are passing using pip 6.0.6 however this is because I temporarily added the --no-use-wheel option (to gauge how much work it was to finish the upgrade). This explains why I'm not yet publishing my changes - I know that a big part of the newer versions of pip is support for (binary) wheels, so I assume that blindly ignoring that feature would disappoint a lot of users :-)
4. Adding proper support for binary wheels will undoubtedly be quite a bit of work, but I guess it will be worth it. I don't want pip-accel to stay behind in the dust of the Python packaging ecosystem, it should be able to take advantage of new initiatives like (binary) wheels.

To end on a high note, here's what the differences in my feature branch currently look like:

peter@macbook> git diff --stat master pip-upgrade
 Makefile              |    6 +--
 pip_accel/__init__.py |  142 +++++++------------------------------------------
 pip_accel/tests.py    |   13 +++--
 pip_accel/utils.py    |   20 +------
 requirements.txt      |    2 +-
 5 files changed, 28 insertions(+), 155 deletions(-)

Note the low number of insertions and the large number of deletions - I always like deleting code during an upgrade or refactor! One reason for this is that the pip developers have been listening to feedback regarding re-usability (amongst other reasons due to @hvdklauw's vocal support of pip-accel - thanks for that) which is much appreciated :-).

I plan to post an update here regarding my progress within a couple of days.

[santagada]

with the new download cache and support for not trying to look on the web for packages (sorry I forgot the -- option for it) pip-accel will actually just be a binary wheel manager (compiling a wheel if it doesn't exists and using it)? Not that I think that the project is without merit, just that I think it will be much easier to be integrated in pip in the future right?

[graingert]

I'm working on upgrading to pip 6, I think the upgrade is mostly done (at least the part without binary wheel support). The main thing that I still need to do is a lot of testing (which I've already started on). I'll try to publish the branch containing the upgrade this week so other people can play around with it as well (I've already been asked to make the work in progress changes available via personal email).

@xolox out of interest what do you mean by "without binary wheel support", that's the only feature that pip-accel could provide on top of pip now that pip 6 supports caching?

[xolox]

@graingert:

out of interest what do you mean by "without binary wheel support", that's the only feature that pip-accel could provide on top of pip now that pip 6 supports caching?

That's your perspective, it's not mine. From the top of my head:

1. pip-accel implements a KISS binary package cache (that can also be stored in an S3 bucket) without the headaches of setting up a local devpi server and without the headaches of Linux ABI compatibility (think binary wheels hosted on PyPI containing *.so files).
2. pip-accel contains support for (automatic) installation of build time dependencies on Debian based Linux distributions (once those build time dependencies have been declared in a configuration file bundled with pip-accel; that file already contains quite a few known build time dependencies).
3. I use pip-accel as a stable API for pip in projects like py2deb.

To summarize, if pip provides everything you need then by all means don't bother using pip-accel. If any of the above features are worthwhile however then you know where to find them :-).

[xolox]

Hi everyone!

Thanks for all of the feedback on this.

I just released pip-accel 0.23 which is based on pip 6.0.x. To get back to the original subject of this issue: --no-install is no longer used, pip-accel now uses pip install --download to "download and unpack but not install" distribution archives.

Please try out pip-accel 0.23, it uses the latest available version of pip (at the time of writing) and includes support for installation of wheels. If you encounter any problems feel free to report a new issue in the issue tracker here on GitHub.

I'm closing this issue because pip 1.4 and 1.5 are a thing of the past now ;-).