Pipenv: Cannot install from a local wheel

[pfmoore]

I have a project where I want to install a package (cassiopeia) that depends on pycurl. I'm on Windows, and pycurl currently does not provide a binary wheel for Python 3.6, nor does it build without a prebuilt libcurl being available. I can however get a wheel from Christoph Gohlke's website.

I'd like to hold the pycurl wheel in my project directory, under wheels/pycurl*.whl. I could then supply --find-links to pip and install pycurl from there.

Specifying an environment variable PIP_FIND_LINKS sort of works, but I can't find any way to record the fact that I want to include the wheels directory in the search path permanently, so that I don't have to (remember to) set an environment variable every time I rebuild the environmnent.

I found https://github.com/pypa/pipfile which gives examples of more complex ways of specifying things in a pipfile, but I can't make this work.

Describe you environment

1. Windows
2. Python version: python 3.6.2
3. Pipenv version: pipenv, version 8.2.6

Expected result

To be able to configure "find-links = ./wheels" somewhere, probably in the Pipenv file, and have it pick up wheels from that location. (I'd expect to be able to use a relative path, to mean "relative to the project directory", or an absolute path for wheels I store globally).

Actual result

I need to manually set PIP_FIND_LINKS before installing via pipenv, and then unset it afterwards, so that it doesn't affect other invocations of pip.

Steps to replicate

pipenv install. Pipfile is

[[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]

Output is:

>pipenv install
Creating a virtualenv for this project…
Using real prefix 'C:\\Users\\pfmoore\\AppData\\Local\\Programs\\Python\\Python36'
New python executable in C:\Users\pfmoore\.virtualenvs\riot_data-4b7hkvZN\Scripts\python.exe
Installing setuptools, pip, wheel...done.

Virtualenv location: C:\Users\pfmoore\.virtualenvs\riot_data-4b7hkvZN
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (17f190)!
Installing dependencies from Pipfile.lock (17f190)…
An error occurred while installing pycurl==7.43.0! Will try again.
  ================================ 8/8 - 00:00:17
Installing initially–failed dependencies…
Collecting pycurl==7.43.0 ----------- 0/1 - 00:00:00

THESE PACKAGES DO NOT MATCH THE HASHES FROM Pipfile.lock!. If you have updated the package versions, please update the hashes. Othe
rwise, examine the package contents carefully; someone may have tampered with them.
    pycurl==7.43.0 from file:///C:/Work/Projects/riot_data/wheels/pycurl-7.43.0-cp36-cp36m-win_amd64.whl (from -r C:\Users\pfmoore\AppData\Local\Temp\pipenv-y27xl4s1-requirement.txt (line 1)):
        Expected sha256 de2980f2839029ffa2917fcc1eb84b2dc736f0a30a5413645e514a2b61df04ed
        Expected     or d6cb0917ce564c9edc377ae436bc0963ee72be8873c90bcce7470f1670c3baef
        Expected     or 1ba222eafcb740805d5c9fe778a47d2704bf764abe9a2546de90f159e4c3a116
        Expected     or f614c93422f31761764a002297b56a0c7f0aeaee7badb0fb43764bda13467697
        Expected     or b0af8badfda56b175e190cf0fb1a18d2bd600a677d3b5d9f7a579823eec74fa4
        Expected     or 9db493308f092b87d8113cea322886f07c2f1b64f9839dffd4a65c300f91244b
        Expected     or 26dcfb05ecbaa27ffaa71a4a3add217ec9e1cee2998b727e1b9e6eff7264d5f8
        Expected     or 413b82b25795dcd0656e2d254892a16f531d88eccabc3a97c9c9451781caf5e8
        Expected     or 89758f2375fe44b139fcc11e305a060c75a4a89178b5066a3894055fe069a80e
        Expected     or 991d221a59c5546370e618241ec05e7d85efd7c5126fb33387de0a12c2cfe8e4
        Expected     or 39a7399e7da031f4648bd6ea273b02c0cf203471b63fe3629d19ebfd13e5701f
        Expected     or 9997e9994860cc99f2622de4133e0dd1756797852645dc6942b58142014f2e59
        Expected     or aa975c19b79b6aa6c0518c0cc2ae33528900478f0b500531dbcdbf05beec584c
        Expected     or 7d1ffc138132a7dcb322d41b1f7d5ed7e2f9bb0dea3103ae5ca25fae2a1f689b
        Expected     or 074a565bc33cfc484fa87339136876f1d8176bd30bb214235e11382b363beef9
        Expected     or d6ac0f902cb82cab13bc9488fb5240cf86325bd24800dc5ab677f8044993f6fc
        Expected     or 61d4b1a2dc1ecdb3b6d4188d63ab884e8768cfc85f37f48c481935b784920137
        Expected     or 1339972f6faf9e7feb54e0d62b018dcea6c99fb5ca46fef4a8d20c2a810d1f2d
        Expected     or 30983ec2f88ee0d26d290f276563c26bc1d302f1f6fc447092368bce7a93f0ea
        Expected     or 9075d35c8bafb96a836a7558b37fe697ec04646f76239254b06e87eb360097c7
        Expected     or 36c3a2d6b4ca31f39ac84fe9b7616d338191f956710c7912c546ffef18600f2f
        Expected     or 024fba378134633694b7a64ec7cb8ef9a98e3ce6b5635247b51b7282b96f33de
        Expected     or 826866c43ef532b7633e24332b7f4bc6b309e72b33631c2b06258fdb284dd55b
        Expected     or 59f637ffe21a90b6155df34b9fdf3030b6453859110db8700bf17f569c6449d6
        Expected     or 614687bdc73246ce85f73b7199d533a222efdda954e84a6bd692fef25fa3b6ac
             Got        7b9443007238914a6cc7fb6c3442aa00f06868b141837097f249adf54add11b6


     ================================ 0/1 - 00:00:01

>pipenv run pip list
Package       Version
------------- -------
cassiopeia    3.0.13
datapipelines 1.0.2
decorator     4.1.2
merakicommons 1.0.2
networkx      2.0
olefile       0.44
Pillow        4.3.0
pip           9.0.1
setuptools    36.6.0
wheel         0.30.0

Note that pycurl is missing from the output of pip list.

[erinxocon]

Hey @pfmoore! Thanks for the report. This is a rough niche situation not having the prebuilt wheel. Being that it is a niche situation I'm gonna mark it as a future enhancement! This will probably need a change to the pipfile spec, which @kennethreitz can weigh in on

[erinxocon]

closing and referencing #909 for all further talk about dep resolution

[pfmoore]

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).

[pfmoore]

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.

[techalchemy]

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 [e-mail] 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.

[ncoghlan]

This may be best reformulated as a docs RFE then, as neither @pfmoore nor I realised sources[n].url could already be a relative path within the repo - we thought it needed to be a network accessible URL.

If we're wrong about that, then that's a very useful discovery, and worth investigating further to see how we might have got that mistaken impression.

[techalchemy]

I should be clear. Pipenv allows you to specify local paths to wheels for specific packages already. It also allows you to define persistent environment variables in a .env file. It is not a replacement for pip; it uses pip. I’m fairly confident that since this functionality exists and can be dropped into the environment, it is probably out of scope for pipenv.

On Oct 18, 2017, at 9:17 AM, Nick Coghlan [e-mail] wrote:

This may be best reformulated as a docs RFE then, as neither @pfmoore nor I realised sources[n].url could already be a relative path within the repo - we thought it needed to be a network accessible URL.

If we're wrong about that, then that's a very useful discovery, and worth investigating further to see how we might have got that mistaken impression.

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

[ncoghlan]

The aim of this RFE would be for folks to be able to do:

git clone <repo_url>
cd the_project
pipenv install --dev
pipenv shell

And have that resulting shell be fully functional for development purposes, even if some of the dependencies are only available as bundled wheel files within the repo.

Right now, that "clone, install & run" outcome can be achieved only if all the artifacts to be installed are available somewhere online (i.e. you're not bundling anything directly inside the repo).

The RFE is thus for there to be a way to tell pipenv to look inside the repo for bundled deps, and for it to remember that fact, and hence rely on it automatically when the repo is cloned in the future.

Setting PIP_FIND_LINKS in a .env file unfortunately isn't sufficient, as that only gets read by pipenv shell and pipenv run (not pipenv install), and the docs explicitly advise against checking .env files in anyway (since the primary intended use case is for credential management): https://docs.pipenv.org/advanced.html#automatic-loading-of-env

[erinxocon]

@pfmoore or @ncoghlan do you have an example repo that has a wheel in it I can test with? Submit a failing test maybe?

[pfmoore]

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?

[techalchemy]

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 [e-mail] 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.

[pfmoore]

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...?

[erinxocon]

I don't think pipenv handles local wheels well. I haven't really had a chance to test though. Been real busy with work!

[pfmoore]

@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.

[techalchemy]

@pfmoore no I actually think this should work, the pipfile spec allows local paths using {path = "../path/thing.whl"} but it is currently broken (apparently) and I'm not sure why yet. So there is 100% a bug here.

[pfmoore]

@techalchemy OK, but you're saying I should explicitly specify the path to the precise wheel, rather than specifying a directory and a requirement? If I were doing this with a requirements file, I'd use the latter, because I'd potentially want to store multiple wheels for different architectures.

But I'm fine with the idea that an explicit filename is the supported approach now, and "define a source that's a local directory of wheels" is an enhancement request. If that's the case, I'm happy to help with testing/fixing the existing bug first, and then lookingat raising the enhancement request.

[techalchemy]

But I'm fine with the idea that an explicit filename is the supported approach now, and "define a source that's a local directory of wheels" is an enhancement request

This is precisely the situation. Currently installing anything as a local path in a project subdirectory fails horribly with no explanation and I haven't had a chance to untangle the exact reason. this is obviously a huge problem, and can be replicated as follows:

$ mkdir /tmp/test
$ cd /tmp/test
$ mkdir dls
$ wget -O dls/requests.zip https://github.com/requests/requests/archive/master.zip
$ pipenv install dls/requests.zip

This also fails with pipenv install ./dls/requests.zip, but works fine if you do the following:

$ cp dls/requests.zip ./
$ pipenv install requests.zip

I suspect it would work similarly well if you copied a wheel into the project root.

[pfmoore]

OK. I'll put together a test using a wheel, and maybe see if I can come up with any ideas for what's happening.

[techalchemy]

Sure thing. I’ve been encouraging some discussion on the irc channel #pipenv on freenode. I’m popping in and out but you can find me as hawkerz. The broader discussion about local paths, files, and (potentially) environment variables should happen in the issue I referenced

On Oct 19, 2017, at 2:20 PM, Paul Moore [e-mail] wrote:

OK. I'll put together a test using a wheel, and maybe see if I can come up with any ideas for what's happening.

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

[techalchemy]

I was posting via email before but the issue I was talking about is #939 which is meant for a discussion about how to approach local files in general. I haven't spent a ton of time troubleshooting this yet but the ideal approach in my mind would be to check if a provided input is a path or file, and, if so, see if we can install it somehow / do dependency resolution

[pfmoore]

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.

[techalchemy]

To answer your question:

1. Pipfiles support local filesystem paths the way I described above. I don't control the documentation, I can only tell you how the implementation works because I pushed for it and am partly responsible for its inclusion in the spec.
2. I already understand that you would like an enhancement whereby you can specify a --find-links parameter in your install, this is not part of pipenv right now but probably isn't that difficult and could also be handled as a passthrough environment parameter to pip or pip-tools, I would assume
3. The remaining issue is that the only option that should currently work for your case is to put the {path = "wheels/package.whl"} entries directly into your Pipfile or to run pipenv install wheels/package.whl from your project directory, however this does not work currently because of a bug nobody has had time to examine

The issue I linked doesn't relate to the syntax of Pipfiles because frankly, there isn't much to discuss. Including a parameter or not is not a technical question or an implementation question, either it gets included or it doesnt. Instead the issue relates explicitly and directly to the design question for dealing with local filesystem paths that are described as relative paths, and how we should handle resolving them as installable (potentially) or not. Broadly speaking, that is something we need to figure out, and at the same time we need to fix the bug preventing installing anything in subdirectories.

Now, point 1 is the most 'involved enhancement option. If point 2 satisfies you, it is probably much easier, but won't be handled until point 3 is finished most likely, since it is a bug with the current codebase which is released in the wild and should be fixed.

Hopefully that helps clear some of that up, no pressure to participate I just wanted to make you aware in case there was anything on the topic that might help with this issue apart from the obvious and already stated

[pfmoore]

Thanks for clarifying. I'll see if I can dig into the bug from point (3), as that seems the most productive.

It seems that much of my frustration stems from how the documentation is structured. I appreciate that's not something you can influence, which is fine. But I would like to flag that issue somehow. Maybe it needs me to raise a new issue and start afresh. I'll try to see if I can work out how to explain the problem I had with the docs clearly enough to do that.

[nateprewitt]

@pfmoore, please feel free to open an issue for the issues you have with the documentation. It's evolved fairy haphazardly and seen some significant revisions recently so I'm not surprised there are gaps.

Once we have those cataloged we can start rallying time to get the docs fixed. If you feel like putting together a PR, that's great too :)

[nateprewitt]

As for the wheel issue, we should be able to support installing local packages that are inside the project, but pipenv historically hasn't really been intended to install arbitrary packages on the file system. The lockfile becomes machine specific at that point and defeats the point of having a reusable setup.

[techalchemy]

@nateprewitt there were a bunch of issues similar to this one where users were bundling relative paths, enough so that Kenneth was willing to update the pipfile spec for it. The original use case was for a path outside of the project directory, but at the very least relative paths inside of the project directory should be in scope (I can't remember how we decided to hash them but I feel that may be causing our recent bugs)

[ncoghlan]

@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.

[nateprewitt]

@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.

[ncoghlan]

@nateprewitt Aye, I think it would be reasonable for paths outside the project to be at least actively discouraged (with a warning), if not outright prohibited.

Even --site-packages can be problematic on the reproducibility front, but at least in that case, the host environment itself is often amenable to automated management.

[techalchemy]

@nateprewitt until #540 (which traverses up one directory _outside_ the project root) we only supported file:// URIs in the pipfile spec. The resolution for that issue added the path keyword and operated in what I think is the way you are describing as being concerned about. I don't think it's wrong to be concerned about it -- I was concerned about the use case at the time, and suggested that any relative paths outside the project directory should be converted to absolute file:// URIs.

I still sort of think this is how we should approach it, although I think Kenneth was adamant that developers who wanted to screw with their pipfiles in such a way should be allowed to have this kind of configuration, and perhaps the lockfile should pin down the path? Not sure what makes sense there.

[techalchemy]

@ncoghlan the thing is pipenv already has built in support for file:// URIs which are, by nature, not portable. Support for this pre-dated support for relative paths, which are substantially more portable, for the most part. I see no reason why we would want to stop people from installing things just because those things might not exist somewhere else, the point of pipenv is to help manage dependencies, not to prevent people from doing things that would work fine with their normal tools.

IMO the questions we should be asking don't revolve around what we should allow users to install, but how we should be representing that information internally both in the pipfile and the lockfile.

[pfmoore]

It may also be worth noting here that personally, I have little or no interest in total reproducibility. I am interested in getting a usable environment, but it doesn't bother me in the slightest if (for example) I get a new version of a dependency if I rebuild my environment.

If that makes me an unusual corner case for pipenv, that's fine - but I got here via the Python packaging user guide, and neither that nor my reading of the docs gave me any impression that pipenv valued reproducibility more than I did. The pipenv docs say that it enables reproducible builds, rather than (for example) promoting them, and mention them under "Pipfile security features", but don't really explain why I should want them (or what I should expect if I don't - for me, machine-dependent absolute paths are fine for most of my projects, so being told I shouldn't use them and the tool deliberately doesn't support them is a clash of goals).

I'm not saying that I mind environments being reproducible - just flagging that as things stand, if the PUG starts recommending pipenv as per its current draft tutorial, you could start getting users arriving here confused as to why their requirements don't match with your priorities, much like I did.

[techalchemy]

Local file installation is resolved in #958

[purEnergy]

I'm curious as to how exactly this is supposed to be used. I'm confused as to what exactly I need to put in the Pipfile and or the Pipfile.lock file in order to install a specific whl package into the pipenv.

If I wanted to install the cryptography package where the relative location from where my pipenv is being executed from is "./install/cryptography-2.1.4-cp27-cp27m-win_amd64.whl", where and how do I put that in the pipenv files? I've tried a number of combinations and nothing seems to work. It just wants to install the version that's already on my local environment which is lower than the version that I want installed in the pipenv. Does the whl have to be in a gz or zip? I don't have a requirements.txt file, but should I?

Here's my Pipfile:
[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"
[dev-packages]
[packages]
cryptography = "*"
[requires]
python_version = "2.7"

Here's my Pipfile.lock:
{
"_meta": {
"hash": {
"sha256": "60e72c1b289a3648291f0eef58dcc4be3b7ecc10dbb128893baa616e5bd4bb26"
},
"pipfile-spec": 6,
"requires": {
"python_version": "2.7"
},
"sources": [
{
"name": "pypi",
"url": "https://pypi.python.org/simple",
"verify_ssl": true
}
]
},
"default": {
"cryptography": {
"hashes": [
"sha256:0d39a93cf25edeae1f796bbc5960e587f34513a852564f6345ea4491a86c5997",
... (removed middle to shorten post)
"sha256:fc2208d95d9ecc8032f5e38330d5ace2e3b0b998e42b08c30c35b2ab3a4a3bc8"
],
"version": "==2.1.4"
}
},
"develop": {}
}

[techalchemy]

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

[techalchemy]

Most especially never ever put anything in your lockfile manually.

[purEnergy]

I tried that, but it still doesn't want to install. I get an error stating that cryptography needs to be >= 2.1.4. Is this a requirement for pipenv to work? Even executing "pipenv shell" gives me this error.

Traceback (most recent call last):
File "C:\Python27\Scriptspipenv-script.py", line 6, in
from pkg_resources import load_entry_point
File "c:\python27\lib\site-packages\pkg_resources__init__.py", line 3142, in
@_call_aside
File "c:\python27\lib\site-packages\pkg_resources__init__.py", line 3126, in _call_aside
f(args, *kwargs)
File "c:\python27\lib\site-packages\pkg_resources__init__.py", line 3155, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "c:\python27\lib\site-packages\pkg_resources__init__.py", line 666, in _build_master
return cls._build_from_requirements(__requires__)
File "c:\python27\lib\site-packages\pkg_resources__init__.py", line 679, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "c:\python27\lib\site-packages\pkg_resources__init__.py", line 872, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (cryptography 2.1.1 (c:\python27\lib\site-packages), Requirement.parse('cryptog
raphy>=2.1.4'), set(['pyOpenSSL']))

[techalchemy]

@purEnergy please file a separate issue where we can troubleshoot your error, instead of using this one

[purEnergy]

Got it. I filed a new issue. I thought this might be related and have been a quick one to solve, but apparently not. Thanks for the help here.