Matt Davis

@bblanchon not really -- revisiting the system flag is one of the next big things on the list though after releasing the refactor away from requirementslib which is out for...

I'm glad you figured out a way to get it to work @rick2ricks -- ideally we can improve this to make it more resilient to different patterns. Also, In the...

## Analysis of Pipenv Issue #6233 **1. Problem Summary:** The issue highlights a problem with Pipenv's handling of environment variables within VCS URLs in the Pipfile. While using an environment...

@rick2ricks could you check if this PR fixes it: https://github.com/pypa/pipenv/pull/6276

@ChaoticRoman you did not report what pipenv version you are seeing that in. We included a fix for sys_platform markers in `2023.8.26` ... whereas before this change it was getting...

@ChaoticRoman I guess I am not seeing what you mean about it not working on `2023.8.26`: `Ignoring requests: markers 'python_version >= "3.7" and sys_platform == "linux"' don't match your environment`...

@ChaoticRoman in my example, which is a clone of `pipenv-bug-demo` it is using the `sys_platform = "=='linux'"` which appears to be working. Could you please review the output I provided...

Interesting -- my patch though for fixing `sys_platform` was to put it into the markers, and so I would think it should be the same behavior as using the markers...

@ChaoticRoman Ok I see what you mean, but the result generated when using markers also seems not desirable because locking on the non-platform doesn't resolve the sub-dependencies either -- but...

@ChaoticRoman I see what is happening, there is logic to actually skip the resolver for markers that don't match, but in the case of sys_platform it gets added to the...