Does host-environment-markers need to be in Pipfile.lock?

[stianjensen]

Why is host-environment-markers part of Pipfile.lock? When working on a repository with multiple developers, this part keeps changing based on who last updated the lock file.

Similar systems, like yarn, does not have this information in their lockfile.

[kennethreitz]

it's useful, as the contents of the lockfile are different when created against different versions of python.

[sigvef]

Can we perhaps add a setting to make it optional? Especially platform_release, platform_system, platform_version and sys_platform in the host-environment-markes tend to change a lot, since developers are running different operating systems.

[kennethreitz]

going to remain, for now.

[brettdh]

I too find this behavior annoying, and strangely at odds with the cross-platform support I see in (if I understand this correctly) pipenv's fetching of environment-specific wheels and hashes.

Are you saying it's useful for some pipenv implementation reason or for pipenv users? I'm having a hard time understanding if you mean the latter.

[tammersaleh]

Our team was just discussing this, and we're unsure as to why it needs to be there. It certainly makes it difficult to use a Pipfile.lock as the source of truth for exact dependency versions. We'd love to see it removed.

[tammersaleh]

Even more strange:

• Generate a Pipfile.lock on macOS
• Commit it to git
• Check it out on a Linux system
• Run pipenv install --ignore-pipfile

Packages are installed correctly, and neither Pipfile nor Pipfile.lock are updated. This makes me even more confused about the purpose of the host-environment-markers section, which clearly didn't stop pipenv from using the Pipfile.lock from a different OS.

[erinxocon]

Tagging @kennethreitz @nateprewitt and @techalchemy

I can see where you guys are coming from but don't know the whole scope of removing it. Hmm

[erinxocon]

@tsaleh You specifically told pipenv to ignore all of that stuff with --ignore-pipfile.

[tammersaleh]

@erinxocon thought --ignore-pipfile only told pipenv to ignore the Pipfile, and not the Pipfile.lock? To be fair, I'm completely new to Python (rubyist), so I'm also not sure about the difficulties of managing python packages (especially across python versions).

[tammersaleh]

To clarify, the test I was trying to run was to determine if pipenv actually needed the information in the host-environment-markers section. It doesn't look to me like it does -- it looks like it'll happily use a Pipfile.lock from another OS, for example.

This is actually good for us, since we're trying to come up with a workflow where our developers can our production deployment tooling can all use the Pipfile.lock with confidence, even though we're a bunch of macOS hipsters.

[erinxocon]

@tsaleh My apologies, you are correct, it does ignore the pipfile. And no alerts are raised about it not being the correct environment?

[tammersaleh]

No, none that I saw. and I just validated that the packages are correctly installed with the right lock versions:

$ pipenv run pip list --format=legacy | grep aiokafka
aiokafka (0.3.1)
$ pipenv graph | grep aiokafka
aiokafka==0.3.1

[nateprewitt]

Hey everyone, host-environment-markers is solely there for auditing purposes and has no effect on the use of the Pipfile. There's a slight possibility a Pipfile generated on Windows may not work on a *nix based platform but I was under the impression this had been solved. If it doesn't, this section of the lockfile won't enforce anything.

I personally don't have an issue removing it but this will require BDFL approval.

[techalchemy]

These markers are there for audit and debugging, and is part of the reason I always ask people for their lockfiles when they have issues. See #295

[brettdh]

@techalchemy could it be moved to a different file that is .gitignored, but still available and maintained separately per-developer (and thus per-platform)?

[nateprewitt]

@brettdh from previous experience when questions about separating pieces into seperate config or logging files have been asked, the answer is no. Kenneth wants to keep everything that is deemed relevant for the project in these two files.

[brettdh]

For debugging purposes, it could be just a separate pipenv command that spits out that information, and then a request (or issue template instruction) to provide it with any new GitHub issue.

[nateprewitt]

@brettdh that's what we've done in Requests and this was Kenneth's design choice after the Requests module had already been implemented. I don't have a problem with a command, but as I said above, this is Kenneth's project and we'll need a go ahead before we do anything like that.

[ZHOUYue67]

For most projects, Pipfile.lock should be checked-in into source control. And putting something always changing like host-environment-markers in Pipfile.lock just doesn't make lots of sense.

If this information is important for debugging purpose, it should be in another file which people can choose to ignore in source control.

Gemfile.lock and yarn.lock got it right.