Use upstream dh-virtualenv

[blag]

I don't think we need to use our own fork anymore, since we don't have any shebang lines that are only #!python.

The update.py script updated more of the Dockerfiles than I expected, so I'm not sure if that's normal or not.

Like before, I'm not really sure what I'm doing here, so any help or direction would be more than welcome.

[blag]

Okay, thanks for that. That brings greater clarity to this, but I still have some unanswered questions:

• Why does upgrading pip break our build?
  • If it's because we are importing from pip to parse requirements.txt files, then we should use the packaging package and specify it in the setup_requires keyword argument to setuptools' setup() function. This does not actually install it onto the system, it just makes it available for the setup.py script, which sounds perfect for our usecase. Source: https://setuptools.readthedocs.io/en/latest/setuptools.html (search for setup_requires, I would link you to it directly but it doesn't have an anchor to link to)
• If this is something that other people are experiencing (and from the linked issue, it looks like people are), can we upstream our changes? It doesn't make sense to me to fork the project, patch it to work for us, and then never submit a PR back to upstream. That just makes it our maintenance burden for no reason.
• Can you help walk me through building the packages, so I can see for myself where the normal shebangs are getting mangled into #!python shebangs? Another alternative solution is to prevent that from happening in the first place, so if we want to whip up a PR for another project to fix that, I'm happy to get on that. I just need to figure out where the #!python shebangs are coming from in the first place.

Sorry if this ends up causing you a lot of work. I'm just trying to solve this in a better manner than what we've been doing so far.

[blag]

Our changes were merged into upstream: spotify/dh-virtualenv#317

Now that StackStorm is Python 3-only, it might make it easier to use upstream's dh-virtualenv, once we have the pip and virtualenv version upgrades figured out.

[blag]

I thought about this a little bit more, and our upstreamed changes have not been included in a released version of dh-virtualenv, and even when they are, that will definitely not be backported to Ubuntu Xenial, and probably not even to Ubuntu Bionic, making this PR pointless.

For ST2 v3.5, we should check the version of dh-virtualenv available in the repos, and see if our changes made it in to the latest version of dh-virtualenv available at that point. If not, then we'll have to wait for Ubuntu 22.04, or even later, to use upstream's version. 😞

Closing.

[arm4b]

At least we could switch to upstream dh-virtualenv, instead of using our fork https://github.com/stackstorm/dh-virtualenv

[jhermann]

My strategy in Dockerfiles is to install sid's dh-virtualenv everywhere, which succeeds when you ignore certain dependencies not relevant for a Docker build.

[blag]

@jhermann I'm glad that works for your use case, but would that work for all of our use cases?

[jhermann]

Works for "packaging some Python software using Docker as the build env". Don't see any other use-cases given the scope of dh-venv.