Closed JobLeonard closed 7 years ago
I would make only two pip packages: loompy (the library) and Loom (the browser). We’re not maintaining the command-line tool, so we should remove whatever is broken and keep only the parts needed to prepare files for browsing. The command thus goes with Loom.
I can help you create the pip packages, it’s very easy.
/Sten
-- Sten Linnarsson, PhD Professor of Molecular Systems Biology Karolinska Institutet Unit of Molecular Neurobiology Department of Medical Biochemistry and Biophysics Scheeles väg 1, 171 77 Stockholm, Sweden +46 8 52 48 75 77tel://+46%208%2052%2048%2075%2077 (office) +46 70 399 32 06tel://+46%2070%20399%2032%2006 (mobile)
On 20 April 2017 at 17:46:10, Job van der Zwan (notifications@github.commailto:notifications@github.com) wrote:
So @slinnarssonhttps://github.com/slinnarsson already made a separte repository for loompy as a pure python library. This is good, but it creates the issue that the version of Loompy in this repo and that repo can go out of sync. It also is only accessible to people who install from Github.
What would make more sense (I think) is to split the code into separate units, all installable through pip, that import each other when necessary
I suggest the following split, could you comment if this is a logical separation Sten?
I'm not entirely up to speed with how Python packages work, but this way (if I'm not mistaken) we can update, say loompy with something faster, and loompy-viewer and loompy-cli will just receive this update downstream after a pip install -U. No syncing inside the repositories necessary.
This should also address the issues raised in #89https://github.com/linnarsson-lab/Loom/issues/89 and #96https://github.com/linnarsson-lab/Loom/issues/96.
Sten, your thoughts on this approach?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/linnarsson-lab/Loom/issues/99, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKKag0sDTDt_gdr26bAFHiTdeVqB8Uusks5rx33BgaJpZM4NDOB_.
Ah, I didn't know the CLI was deprecated. Well, that simplifies things, right? We can copy the current configuration to the loompy repo, and then we modify this one to become Loom
(although I suspect that already exist as a name, hence the suggestion of loompy-viewer
as a name). Let's split it up when I'm back, then you can show me how it works. Should be relatively straightforward, right?
Ok, so I'll work on fixing the loom-viewer python code. We should remember to update the readme's for both to refer to the current set-up, as well as generally fix outdated info (we're still referring to the loom CLI for example)
Argh.
Supervisor does not work on Python 3. This is the master branch, which has work-in-progress support for Python 3. Supervisor is very likely to crash, cause subprocesses to hang, or otherwise behave unexpectedly when run on Python 3. See issues running Supervisor on Python 3. It may also have regressions on Python 2 as a result of attempts to add Python 3 support. Help from developers with Python 3 porting experience is needed. Do not use this branch on any production system.
https://github.com/Supervisor/supervisor
I'm looking for alternatives. Circus might be one.
I think we got all the big bugs now, right? There might be a few lurking here and there, but we'll fix those as we encounter them
So @slinnarsson already made a separte repository for loompy as a pure python library. This is good, but it creates the issue that the version of Loompy in this repo and that repo can go out of sync. It also is only accessible to people who install from Github.
What would make more sense (I think) is to split the code into separate units, all installable through
pip
, that import each other when necessaryI suggest the following split, could you comment if this is a logical separation Sten?
loompy
python library, doesn't import anything else.loompy-viewer
constains server/browser and browser code, requires loompy (mainly for the HDF5 fallback in case expanded data is not present).loompy-cli
installs theloom
command, depends on bothloompy
andloompy-viewer
, contains expansion codeI'm not entirely up to speed with how Python packages work, but this way (if I'm not mistaken) we can update, say
loompy
with something faster, andloompy-viewer
andloompy-cli
will just receive this update downstream after apip install -U
. No syncing inside the repositories necessary.This should also address the issues raised in #89 and #96.
Sten, your thoughts on this approach?
loompy
repository the one that is pip-installableloompy-viewer
, depending onloompy
split CLI code into separate repository, installable asloompy-cli
, depending onloompy
andloompy-viewer
loom-viewer