Problem with python-dateutil requirement

[Gonza10V]

I'm writing a package that automates DNA assembly in an Opentons OT-2, which has a a read only version of date ultil: python-dateutil 2.7.5. I would like to know how is used python-dateutil so I can think in some solutions. Some alternatives could be:

• Skip that requirement (is it possible?)
• Fork a version and set requirements to use python-dateutil 2.7.5
• Divide my package into two, one to work in the user computer that can use pySBOL3 and another installed in the OT-2 that does not require pySBOL3. Could you give some advice or guidance to use pySBOL3 in this project?

Here is the last part of the error for context:

Requirement already satisfied: zipp>=0.5 in /usr/lib/python3.7/site-packages (from importlib-metadata->click<9,>=8.0.0->opentrons->pudupy) (3.5.0)
Requirement already satisfied: wcwidth in /usr/lib/python3.7/site-packages (from prettytable<3.0.0,>=2.2.1->pyshacl~=0.18.1->sbol3->pudupy) (0.1.7)
Installing collected packages: python-dateutil, pyparsing, isodate, rdflib, owlrl, prettytable, pyshacl, sbol3, pudupy
  Found existing installation: python-dateutil 2.7.5
    Uninstalling python-dateutil-2.7.5:
Could not install packages due to an EnvironmentError: [Errno 30] Read-only file system: 'isoparser.pyc'

[tcmitchell]

@jakebeal I'm interested to hear your thoughts on this.

I see that python-dateutil 2.7.5 dates from 2018. That's pretty old. It's also quite understandable that an Opentrons machine would have an older version and would have a read-only file system.

pySBOL3 requires any 2.8 version of python-dateutil, with a minimum version of 2.8.2 (released July, 2021). If we were to relax that we would have to confirm that the required APIs that pySBOL3 uses did not change between version 2.7.5 and 2.8.x. We would also need to release a new version of pySBOL3 with this relaxed dependency.

A quick grep shows that the only place dateutil.parser is used is in datetime_property.py to parse dates. Since dateutil.parser is a very general parser it will be hard to say how broadly compatible version 2.7.5 would be.

@Gonza10V could you please try the forking approach? You should be able to modify the python-dateutil dependency in setup.py as follows:

diff --git a/setup.py b/setup.py
index fe0b087..9aa5ddb 100644
--- a/setup.py
+++ b/setup.py
@@ -39,7 +39,7 @@ setup(name='sbol3',
             # Require at least rdflib 6.1.1, and allow newer versions
             # of rdflib 6.x
             'rdflib>=6.1.1,==6.*',
-            'python-dateutil~=2.8.2',
+            'python-dateutil~=2.7.5',
             'pyshacl~=0.19',
       ],
       test_suite='test',

Let's leave this issue open and see how that goes. Please let us know if you are successful, or if you need any additional help. It sounds like an exciting and interesting project. We will be happy to help you!

[jakebeal]

My thought is that this is going to turn out to be one instance of a more general problem if the OT-2 has a lot of fixed packages installed that will continually go more out of date.

What I don't currently understand is the relationship between the OT-2 environment and the sbol3 installation. Presumably you're running your software on the actual machine, but does it need to be in literally the same environment as the OT-2's installations? Could you use a virtual environment for running your software so that you don't have to depend on the fixed OT-2 package environment?