Move build configuration to static configuration files

[jakelishman]

Summary

This removes the vast majority of the dynamic code from our setup.py files, and instead uses static configuration to specify them. As part of this, we also use a single VERSION.txt as a single source of truth for both the qiskit-terra main package and the qiskit "metapackage". This should avoid a situation where we let the two get out of sync during a release, which can cause us severe problems for fixing the problem with respect to git tags.

Summary

Details and comments

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 7037526759

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 5 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.003%) to 87.441%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
crates/qasm2/src/lex.rs	4	91.67%

Totals
Change from base Build 7035250835:	-0.003%
Covered Lines:	59766
Relevant Lines:	68350

---

💛 - Coveralls

[mtreinish]

Overall this LGTM, it's am much simpler state for managing the package. Using static config files for package metadata makes a lot more sense. Just a few small inline comments. Also do you know if this changes the minimum pip version we can use?

[mtreinish]

These are good additions. While we're modifying the metadata, did you want anything compiler related here?

[jakelishman]

Oh, I think I just made sure it was synchronised with the tags on the GitHub repo, rather than going out my way to add things. We can add "quantum compiler" to both if you thing it'd be good?

[mtreinish]

Nah it's fine, we can always tweak these later if needed.

[mtreinish]

This seems less than ideal, but in practice I guess people aren't using the all extra very frequently. I can't think of a better way to do this besides copy and pasting the component lists for all too. I'm guessing we can't use dynamic for optional dependencies because that's my only other thought.

[jakelishman]

Yeah, it's not super ideal, though I was assuming .[all] isn't being used at all.

[mtreinish]

Wouldn't exclude = [""test*"] be more consistent with what we were doing before?

[jakelishman]

It would be more consistent and I can switch it over to that if you prefer. I think the include-list form is maybe a bit less liable to silently break than an exclude list, though.

[mtreinish]

That's fine with me, this works.

[mtreinish]

This LGTM now just one quick question inline, but I don't think it makes a big difference either way.

[mtreinish]

Should we add?

Suggested change

	license = { file = "LICENSE.txt" }
	license = { file = "LICENSE.txt", text = "Apache 2.0" }

I'm not sure if this is valid syntax or not though. I was doing one final pass through comparing the old setup.py with the metadata in the pyproject.toml and noticed we had the license string set before (and the file was pulled in implicitly I think) but now we just point to the file. But I also need to read PEP 639 to see if this matters at all either.

[jakelishman]

The current PyPA guidelines say it's either-or (though maybe others interpret that text differently), so maybe it's best to just revisit when PEP 639 is accepted?

[mtreinish]

Yeah, we can look at it again if/when pep 639 is accepted.

[jakelishman]

For the top question, which I didn't answer: I don't think this changes anything about the pip version, though it might require some newer setuptools features to support the dynamic tables. I don't know what the minimum version of it is, though - setuptools' documentation isn't great at that.