pipenv: Cannot install from a local wheel

Hmm, I’m not sure it’s that niche. Needing to use prebuilt wheels is fairly common on Windows, and Christoph Gohlke maintains an extensive and well-known archive of such wheels, particularly for the scientific stack (although it is true that more and more projects now host wheels on PyPI). So while I’m OK with the idea that it’s an enhancement, I think it’s a fairly important use case.

Also, even if it’s not supported directly by pipenv yet, documentation on ways of working round the limitation would be useful (I assume that hosting the wheel in a local index like devpi would work, for example).

@erinxocon No problem. I completely understand.

My main question isn’t so much whether things work well/badly, or even if there’s a bug. My real question is whether this scenario is currently supported or not. If it’s not supported, that’s fine - I can raise a new feature request explaining my requirement and asking if it could be supported. If it is supported, then the docs don’t explain it very well. If someone can clarify how to set things up, I’m happy to try to write a doc PR to improve things. (There may also be bugs in the implementation, if it’s not a well-used feature - I’m happy to be a guinea pig in that case, and report any problems I hit).

My impression is that actually, this simply isn’t something anyone has thought through, so it might work, but more as a side-effect of how other features work than as a fully fleshed out use case. If that’s true, I’d be inclined to just treat it as a feature request, rather than struggle to try to make the existing features handle an unexpected corner case.

Actually, #909 doesn’t seem that related. What I’m specifically looking for is a way to specify that a directory within the project holds artifacts (probably wheels, but potentially sdists as well) that should be considered as a source. Something like

[[source]]
bundled_artifacts = "relative_path_within_repo"
name = "bundled"

which could then be referenced like any other source.

By limiting it to relative paths within the project, it avoids the possibility of depending on context that’s only available on the local system.

See the discussion on https://github.com/pypa/python-packaging-user-guide/issues/373 for more context.

Hmm. That seems to be about local files on the command line (pipenv install foo) where I can see that there’s a need to address the confusion between a package name and a local directory. My issue here is about manually editing Pipfile to explicitly state my intention.

To be frank, I think I’ve got a badly skewed mental model of how pipenv works, and that means I can’t see the connection you’re suggesting. My main priority should likely be to understand the correct approach to using pipenv before I try to work on solutions. But I’m not quite sure how to do that.

The way I got to where I now am is as follows - the docs start by showing how to use pipenv install foo in a new project directory to start setting up the working environment for your project. From there, “Basic Usage” shows what Pipfile looks like, but it still mostly talks in terms of a model where I use pipenv install to add packages, and don’t manually edit Pipfile.

My use case (where installing from PyPI fails due to a lack of a binary wheel) clearly dumps me into “Advanced Usage” territory. Here, “Specifying Package Indexes” sounds like exactly what I’d want, but it’s only for PyPI style URLs, not for local directories of packages. That’s where my suggestion of adding syntax to [[source]] came from.

There’s nothing else in the pipenv docs that looked relevant to me, but the example in https://github.com/pypa/pipfile includes a “file=” option for a package, but that uses a URL, not a path (and file: URLs are basically hopeless to use for relative files, or absolute Windows paths).

That’s the point I came here.

1. The pipenv documentation implies I should be writing a [[source]] section, but doesn’t tell me how to do that for a local directory (it implies it’s more like --index-url than --find-links in pip terms).
2. The pipfile documentation provides file= but it implies that only URLs are supported, and it doesn’t support having a set of wheels in a directory, with the correct one chosen based on compatibility with the platform.

The discussion here leads me to think that (1) is an enhancement request. And (2) in principle works but has bugs (and has the limitations I note above). But #939 doesn’t seem to relate to Pipfile syntax at all, but rather to command line usage, and I’m reluctant to add my confusion to that issue as well as to this one…

For my current project, I’ve (at least for now) abandoned pipenv, and reverted to pew plus a requirements file. I’m happy to help get pipenv to a point where it handles what I’m doing, but I’m struggling to understand how I can contribute usefully. Maybe I’m better, now that I’ve explained my use case, to step back and leave the experts here to consider it.

Sorry, I’m confused. As I understand it, it’s not possible to have file URLs for relative paths (and if it is, the rules for constructing them in a cross-platform manner seem obscure at best).

Can you explain the syntax I’d use to say “the file pycurl-7.43.0-cp36-cp36m-win_amd64.whl stored in the wheels directory that exists alongside the Pipfile file”?

I’m confused as to what’s being said here. Is this an existing, supported, capability in pipenv? @erinxocon seemed to be saying in https://github.com/kennethreitz/pipenv/issues/914#issuecomment-337439874 that it was a future enhancement…?

Don’t put anything in either file manually. pipenv install ./file.whl

@ncoghlan to clarify, I’m completely for relative paths to packages in the project. I stated that in other comments this evening, sorry it didn’t make it into this one.

What we have previously been against is allowing people to specify arbitrary paths to, for example, something the have in their downloads folder or desktop. These are the kinds of things I’d prefer we avoid and I think historically we have.

@nateprewitt “But reproducibility…” was my initial reaction as well, but then @pfmoore pointed out that the idea behind using a relative path is that it means you can easily bundle the relevant wheel files with the affected source project, similar to the way CPython handles bundling pip and setuptools for the sake of ensurepip.

That then actually ends up improving environmental reproducibility, since you get the otherwise-tricky-to-obtain dependencies right along with the source code.

The file specification requires real file URIs. Pipfiles ca man use path instead for relative locations

On Oct 19, 2017, at 3:44 AM, Paul Moore notifications@github.com wrote:

Only a local one at the moment, but I can put it on github. It’s nothing more than a directory with a subdirectory “wheels” and in there a wheel downloaded from http://www.lfd.uci.edu/~gohlke/pythonlibs/

There’s no Pipfile precisely because I don’t know how to specify what I’m trying to achieve. Or I caould add the one from above:

[[source]] url = “https://pypi.python.org/simple” verify_ssl = true name = “pypi”

[packages] cassiopeia = “*” pycurl = {file = “./wheels/pycurl-7.43.0-cp36-cp36m-win_amd64.whl”}

[dev-packages] but that doesn’t do what I want, so I’m not sure how useful that would be to you?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

You can specify local paths in your pipfile already and you can specify project environment variables in a .env file per the documentation.

On Oct 18, 2017, at 8:58 AM, Paul Moore notifications@github.com wrote:

Actually, #909 doesn’t seem that related. What I’m specifically looking for is a way to specify that a directory within the project holds artifacts (probably wheels, but potentially sdists as well) that should be considered as a source. Something like

[[source]] bundled_artifacts = “relative_path_within_repo” name = “bundled” which could then be referenced like any other source.

By limiting it to relative paths within the project, it avoids the possibility of depending on context that’s only available on the local system.

See the discussion on pypa/python-packaging-user-guide#373 for more context.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.