@tflink: Can you please have a look at this as well? Does this make sense?

In D337#6136, @kparal wrote:

Require exact versions in requirements.txt

After wasting more of my life on packaging woes and reading some clever
articles like these [1], I provided exact version specification in
requirements.txt, so that we have an exactly defined environment when
pulling from pypi. We can't do that in our spec file, so let's use >=
instead. Let's keep these versions in sync, always keeping the to
minimal supported version. As a starting point, I used the current
versions we use in dev and stg environment.

While I understand why you set the versions in requirements.txt, I'm not so sure that setting specific version requirements is a great idea. IIRC, requirements.txt doesn't set things in stone like putting the deps in the setup.py but what happens when we want to work on el7 and rawhide? The dependencies we control should be fine but I suspect that the deps we don't control won't have the same versions in both repos.

When the versions are set in setup.py, the setuptools entry points just blow up if the versions don't match exactly and that's not the kind of thing that's caught during rpm build unless you have functional tests which poke at that entry point from the command line. I've lost track of the number of times that's bitten me while deploying blockerbugs.

I propose a compromise - hard set the deps under our control and be a bit looser about the ones that we don't. We'll still need to be more vigilant about making sure that the specfile, requirements.txt and reality match up properly

pyaml - nothing seems to import this anymore

Not sure how you came to this conclusion. PyYAML (provides yaml) is still imported in 6 places that I can see from a quick git grep and is rather critical to formula parsing.

In D337#6149, @tflink wrote:

While I understand why you set the versions in requirements.txt, I'm not so sure that setting specific version requirements is a great idea. IIRC, requirements.txt doesn't set things in stone like putting the deps in the setup.py but what happens when we want to work on el7 and rawhide? The dependencies we control should be fine but I suspect that the deps we don't control won't have the same versions in both repos.

I thought that pypi was always the same, regardless of your base system. Meaning you can pull the same packages, the same versions, whether you are on Fedora 20/21/22/rawhide or RHEL or Debian or something else. Isn't this the case?

The problem would be with the spec file, and that's why I used >= instead of == in the spec file, so that we can easily build it on e.g. Rawhide against newer packages.

When the versions are set in setup.py, the setuptools entry points just blow up if the versions don't match exactly and that's not the kind of thing that's caught during rpm build unless you have functional tests which poke at that entry point from the command line. I've lost track of the number of times that's bitten me while deploying blockerbugs.

And do you prefer this to blow up or not? requirements.txt are not affected like this, because they are only used during manual libtaskotron git checkout and virtualenv use. But I'm not sure whether you consider this to be a benefit or a drawback.

I propose a compromise - hard set the deps under our control and be a bit looser about the ones that we don't. We'll still need to be more vigilant about making sure that the specfile, requirements.txt and reality match up properly

By being looser, you mean using >= in the requirements.txt? Or just leaving out the version completely?

pyaml - nothing seems to import this anymore

Not sure how you came to this conclusion. PyYAML (provides yaml) is still imported in 6 places that I can see from a quick git grep and is rather critical to formula parsing.

There's a trick. pyaml != PyYAML :-)

Oh, one more thing. I removed py as well, because I couldn't find anything that uses it.

I have made too many changes at once, so let's split it. I'll upload separate patches for individual steps, so that we can easily accept those obvious changes, and have easier discussion about those possibly controversial changes.

Since Tim had most concerns, I removed Martin and Josef from reviewers, so that it doesn't show up in their queues needlessly, but it shows up in Tim's (at least this is the way Phab works, I think). No rush in responding, this is not high priority. I'm just tidying up.