Fix CI failures caused by a urllib3 version conflict.

[bjones1]

Fixing CI failures due to urllib3 version disagreements in RunestoneInteractive/rs#37.

[bjones1]

It looks like an occasional failure due to timing problems; I think this PR is OK.

[bjones1]

I don't think moving to Poetry would be that difficult for this case -- we already know most of what we need to make the change.

[bjones1]

My commit message is wrong/outdated. Do you want me to force-push a fixed commit message? (No changes to the files.)

[bnmnetp]

I worry that a runestonecomponents-dev is just a band-aid on a band-aid and we are just giving poetry an even longer list of things to try to reconcile. It already takes a LONG time to figure it out - multiple minutes for me on fast hardware!!. At some point I fear even poetry is going to not be able to find the greatest common denominator for three large projects.

Some wild ideas.... Read them all before commenting some of them make less sense than others.

1. We could Put runestonecomponents in their own docker container so we just do docker run runestone build
2. We could create three virtual environments one for each of BookServer, RunestoneServer and RunestoneComponents and make sure that we run each command inside their own virtual env.
3. We can wait it out... I think that the components are only a dependency for the server so that we can build previews and do testing stuff... Eventually building will be replaced by pretext-cli so maybe we can limp along...
4. On further looking we do import from runestone in a couple of other places... feedback.py for lp and scheduled builder... Maybe a bit of refactoring can create more independence? a minimal runestone-common module? Maybe some code can just be moved to runestone? At first glance it seems like the LP stuff we import is trivial...
5. Put on our thinking caps and figure out how to refactor all of this into one or more packages than can support each of the major applications..
6. Put everything into one giant repo with one giant pyproject.toml. -- last for a reason

[bjones1]

Thinking about this, our long-term goal is to remove all Python code except for tests. In this final state, dependencies become easy to reconcile. But:

• What's the time frame for removing Sphinx support? I assume this won't happen until all books are building in PreTeXt, which (I assume) will take a while.
• There are still database operations that need to happen when a Runestone Component is defined. Currently, the pavement.py files import from runestone.server and a few of my literate programming components get imported in the server-side feedback routines as well. We need to factor these out eventually.

[bjones1]

I worry that a runestonecomponents-dev is just a band-aid on a band-aid and we are just giving poetry an even longer list of things to try to reconcile. It already takes a LONG time to figure it out - multiple minutes for me on fast hardware!!. At some point I fear even poetry is going to not be able to find the greatest common denominator for three large projects.

I don't think this will make much difference -- we're already resolving everything except for the requirements-dev.txt in the current Poetry process. I suspect we're already requiring a lot of those dev dependencies elsewhere already (pytest, etc.).

1. We could Put runestonecomponents in their own docker container so we just do docker run runestone build

The current problem is just within the components themselves, so we still have a problem even in this case. We need Poetry or something like it that will help us sync dependencies and dev dependencies for a project.

However, I do agree that we should start looking at ways to factor out code in the Runestone Components to some other shared location for now. For example:

• A pip-installable lib containing shared dependencies: database access, location of books/files, etc.
• The pip-installable BookServer, which depends on this lib.
• The Runestone server, which will eventually be the instructor interface server
• The Runestone components, which we distribute as an NPM package.

2. We could create three virtual environments one for each of BookServer, RunestoneServer and RunestoneComponents and make sure that we run each command inside their own virtual env.

I like this. The first step in this direction is the shared library mentioned above.

3. We can wait it out... I think that the components are only a dependency for the server so that we can build previews and do testing stuff... Eventually building will be replaced by pretext-cli so maybe we can limp along...

Honestly, this is my second-favorite approach. As we refactor, this gets simpler. But, we might get to a point where the tests break, then we're back to looking for a better solution.

4. On further looking we do import from runestone in a couple of other places... feedback.py for lp and scheduled builder... Maybe a bit of refactoring can create more independence? a minimal runestone-common module? Maybe some code can just be moved to runestone? At first glance it seems like the LP stuff we import is trivial...

Yes, we should definitely work on this.

5. Put on our thinking caps and figure out how to refactor all of this into one or more packages than can support each of the major applications..

This seems fairly similar to the previous idea -- I don't understand what the difference is.

6. Put everything into one giant repo with one giant pyproject.toml. -- last for a reason

Aack!

[bjones1]

I'm still guessing that moving to Poetry would be a good short-term fix...