Possible usecase for multiple groups.

[proofit404]

Hi. I remember that we agree to do only default and dev group at this moment.

I want to explain my seeing of this feature if you decide to revisit this issue in the future.

We have customer who runs our web application written in python in its own cloud. Our application depends on few closed source packages developed for our customer by another team. We don't have access to this packages, but know provided api.

For testing purpose this team create stubs packages which we can install from PyPI installation running by our customer.

Before deploying new app release to staging infrastructure new code is reviewed by customer programmers team. In staging environment customer devops install real packages with known names from another PyPI instance running at customer staging environment. After QA engineers approved new release same installation shipped to the production environment where customer PyPI instance running on another url.

So it's good to have something that can handle this tricky setup easily. I see it like

[packages]
customer_package_foo = "*"
customer_package_bar = "*"

[packages:staging]
<<inherit packages from previous section>>
<<pin real dependencies of foo and bar packages>>
<<provide staging pypi url>>

[package:prod]
<<inherit packages from staging>>
<<provide prod pypi url>>

[dahluwalia-ag]

There does not seem to be a way to specify one version for one OS and another for a different OS.

Example:
I want to specify celery < 4 for windows and celery latest for linux.

Is there a solution for this?

Thanks!

[kennethreitz]

@dahluwalia-ag no.

[dahluwalia-ag]

Okay, I will use setup.py to specify this difference, and then the pipfile to install itself.

Pipfile

[packages]
"e1839a8" = {path = ".", editable = true}

setup.py

...
install_requires=[
        'Celery<4;platform_system=="Windows"', 'Celery;platform_system!="Windows"',
...