old pysbol repo: add tag to the latest commit

[kenza12]

Hi @bbartley @kirichoi ,

I’m a bioinformatic engineer working at INRAE institute in Jouy en Josas (France) with BioRetroSynth Team. I’m working on Galaxy Synbiocad Project (https://www.jfaulon.com/galaxy-synbiocad-portal/). I’m packaging a suite of tools mainly in conda-forge channel which includes sbml2sbol, a tool developed by neilswainston which convert sbml format to sbol (https://github.com/neilswainston/SbmlToSbol). This tool have some dependencies like pysbol: https://github.com/SynBioDex/pySBOL. In order to package sbml2sbol, I need to package pysbol first in conda-forge channel. I know that pysbol2 is already available in conda-forge but it doesn’t give us the expected results. We need the older version of pysbol.

I’m contacting you because I encountered an issue with this tagged pysbol package 2.3.0 : https://github.com/SynBioDex/pySBOL/releases/tag/2.3.0. It doesn’t include some Linux directories and windows files. But I made a test with the latest and actual version which works fine, but it’s not tagged: https://github.com/SynBioDex/pySBOL.

I was wondering if it’s possible for you to tag the pysbol package according to the latest commit in order to have the latest version which includes all the needed directories and files.

Sorry if I opened an issue in this repository (pysbol2) instead of pysbol but I don’t have the rights to open it in an archived repository.

Thanks in advance,

Best wishes,

Kenza BAZI KABBAJ

[bbartley]

@kenza12 there are potentially a couple of solutions here -- can you install the original pysbol into your environment via pip install pysbol rather than from the github repo? Let me know. Otherwise, I will tag the latest release.

Just curious, can you say more about why pysbol2 does not seem to work in your current environment? Is it an issue we might fix, enabling you to upgrade to pysbol2?

[kenza12]

Hi @bbartley ,

Thank you for your answer.

Indeed, I can use pip to install pysbol in my conda environment but it’s not allowed to use it for building a package in conda-forge. Pip and Conda are two separate packaging systems which may lead to version incompatibilities.

About pysbol2, I can’t give you a precise explanation. All I can tell you is my colleagues @breakthewall @tduigou noticed an unexpected structure of the sbol output which doesn’t work with PartsGenie tool (https://pubmed.ncbi.nlm.nih.gov/29949952/). But when they use pysbol, PartsGenie succeeds to parse the sbol file without an error.

Thanks again.

Best wishes,

Kenza BAZI KABBAJ

[bbartley]

@kenza12 so just to confirm, the HEAD of the pysbol repo containing the latest commit is working for you, and you need that version tagged?

[tduigou]

Hello, I work with @kenza12. I anwser for her: the commit we need to be tagged is the one that corresponds to the "2.3.3.post9" pysbol package in pypi (https://pypi.org/project/pySBOL/2.3.3.post9/), released in May 19, 2020.

Best wishes,

[kenza12]

Hi @bbartley ,

Sorry I wasn’t at the office last week. I confirm what my colleague @tduigou said to you about the needed tag : 2.3.3.post9 for pysbol package.

Thanks in advance.

Best wishes.

[bbartley]

@kenza12 @tduigou I have created a new tag here: https://github.com/SynBioDex/pySBOL/releases/tag/2.3.3.9

Please let me know if it is working for you.

[kenza12]

Hi @bbartley ,

Thanks for the tag. I could build a package for OSX and Windows without an error but it didn’t work for Linux system:

Python 3.7.10 | packaged by conda-forge | (default, Feb 19 2021, 16:07:37) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sbol
Traceback (most recent call last):
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/site-packages/pySBOL-2.3.3.post9-py3.7.egg/sbol/libsbol.py", line 23, in swig_import_helper
    return importlib.import_module(mname)
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 670, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 583, in module_from_spec
  File "<frozen importlib._bootstrap_external>", line 1043, in create_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
ImportError: libxslt-6cbe83bf.so.1.1.17: cannot open shared object file: No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/site-packages/pySBOL-2.3.3.post9-py3.7.egg/sbol/__init__.py", line 6, in <module>
    from sbol.sbol import *
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/site-packages/pySBOL-2.3.3.post9-py3.7.egg/sbol/sbol.py", line 17, in <module>
    from .libsbol import *
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/site-packages/pySBOL-2.3.3.post9-py3.7.egg/sbol/libsbol.py", line 26, in <module>
    _libsbol = swig_import_helper()
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/site-packages/pySBOL-2.3.3.post9-py3.7.egg/sbol/libsbol.py", line 25, in swig_import_helper
    return importlib.import_module('_libsbol')
  File "/home/kenza/anaconda3/envs/sbol_dev3/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_libsbol'

As you can see, libxslt-6cbe83bf.so.1.1.17 is missing. This version 1.1.17 is not available in conda-forge. Only 1.1.29, 1.1.32, 1.1.33 are available in conda-forge.

I know it is extra (unuseful) work for you but would it be possible for you to use one of the versions available on conda-forge instead of 1.1.17?

Thanks for your time.

Best wishes.

[bbartley]

@kenza12 apologies for the long delay. I'm afraid that rebuilding the linux wheels is probably going to be very difficult and time consuming. There may be an easier path by fixing any issue that is preventing you from upgrading to pysbol2. Would it be possible to provide the PartsGenie SBOL file that parses correctly with pysbol but breaks on pysbol2? @breakthewall @tduigou

[kenza12]

@kenza12 apologies for the long delay. I'm afraid that rebuilding the linux wheels is probably going to be very difficult and time consuming. There may be an easier path by fixing any issue that is preventing you from upgrading to pysbol2. Would it be possible to provide the PartsGenie SBOL file that parses correctly with pysbol but breaks on pysbol2? @breakthewall @tduigou

Hi @bbartley,

Thanks for your reply and your proposal,

Please find attached the file generated by SBOL2 which is not working with PartsGenie tool pathway.sbol2.txt and the other one which is generated by SBOL pathway.sbol.txt and working very well with PartsGenie.

I converted them to txt format because xml type is not supported here.

Thank you again. We appreciate your effort.

Best wishes,

@kenza12 @breakthewall @tduigou

[jakebeal]

@kenza12 @tduigou : in resolving https://github.com/SynBioDex/pySBOL/issues/138, I recently switched several of the tools in this toolchain from pySBOL to pySBOL2.

In the process, I found that a common error in these tools was to assume that objects will appear in lists in a sorted order. This is a fragile assumption: ordering is not guaranteed by SBOL and cannot be relied on with the pySBOL library, but does happen to appear when pySBOL is used in certain patterns.

A brief inspection of the two files that you provided shows that the one generated by pySBOL2 is not in alphabetical order, while the one generated by pySBOL is. This suggests that PartsGenie may have the same error as the other tools did.