switching to dev mode again

[baentsch]

Moving version number forward. Also tests MacOS CI dependencies.

[dstebila]

In my own dev environment I've been getting annoying python3 failure messages from brew that mention pipx, but I haven't figured out what I'm actually supposed to do. Is it as simple as using pipx instead of pip3 everywhere?

[baentsch]

In my own dev environment I've been getting annoying python3 failure messages from brew that mention pipx, but I haven't figured out what I'm actually supposed to do. Is it as simple as using pipx instead of pip3 everywhere?

No clue yet. Without local MacOS environment, I'm trying remote CI debugging right now. Turnaround sucks. If you'd have time and a local environment with the same problem, please give it a go.

[dstebila]

In my own dev environment I've been getting annoying python3 failure messages from brew that mention pipx, but I haven't figured out what I'm actually supposed to do. Is it as simple as using pipx instead of pip3 everywhere?

No clue yet. Without local MacOS environment, I'm trying remote CI debugging right now. Turnaround sucks. If you'd have time and a local environment with the same problem, please give it a go.

It seems like this is a general Python ecosystem change, not just macOS, so eventually you may have this problem to look forward to on Linux. Apparently the idea is to force people to do package management properly. At least that's what I learned from this discussion thread

pipx is apparently not a drop-in replacement for pip3; in particular pipx won't work with libraries, only applications, and the case in which I encountered this was about a library. For libraries apparently the preferred approach is to create a virtual environment (yuck) that installs the desired library locally for the place you're using it, rather than system-wide. It is apparently possibly to bypass the restrictions on pip3 and get the behaviour we're used to by passing the flag --break-system-packages, but this is not preferred since it doesn't do proper package management.

[baentsch]

since it doesn't do proper package management.

Do we need to care about this in a temporary CI environment? Just giving the option a go....

[dstebila]

since it doesn't do proper package management.

Do we need to care about this in a temporary CI environment? Just giving the option a go....

Probably it's fine, give it a try.

[baentsch]

Probably it's fine, give it a try.

Just done -- without DCO/-s option, though :-( That anyway makes me wonder: Why did we activate that? Wouldn't it be more reasonable that maintainers add this to commits while reviewing and not contributors? Any documentation how LF wants us to use this feature?

[baentsch]

Probably it's fine, give it a try.

Just done -- without DCO/-s option, though :-( That anyway makes me wonder: Why did we activate that? Wouldn't it be more reasonable that maintainers add this to commits while reviewing and not contributors? Any documentation how LF wants us to use this feature?

Tagging @ryjones also here: Any documentation that'd help us understand what you want us to do wrt DCO?

[baentsch]

For now, I try to remember adding "-s" to commit messages. Not exactly rocket science, but I'm not sure what this buys us (or any other committer). But again, suggest to add this new LF formalism "HowTo" also to https://openquantumsafe.org/about/#getting-started.

[baentsch]

@SWilson4 please provide second review and approval to this "quick fix". I think this is acceptable at this time as OQS did not agree to provide "production grade" software, so an addition like --break-system-packages seems "OK" for now.