Background

PyXNAT has proven a valuable tool for XNAT, and the 0.x series is somewhat stable at this point.  Some sort of plan for the future is in order.

When/where

Friday, 1:00-?, Room 207.

Who

  • Christian (lead)
  • Rick (lead)
  • Scott Burns (in absentia)
  • Dave J (Mayo)
  • Ben Wagner
  • Miklos Espak
  • Shree Unde

Outcomes

We need to decide the practical aspects of maintaining pyxnat, perhaps moving it to XNAT's bitbucket.  Being able to use XNAT's Jira for bugs (bugs to bugs@xnat.org can be shunted to pyxnat) will be helpful.  We need to coordinate this with Yannick.

A developer round table area will be set up for continued conversation.

Christian will draft and circulate a road map for (at least short-term) continued development.

Specific issues:

  • Better documentation is needed.
  • Better debugging/logging messages are needed.
  • Some performance issues need to be addressed (Ben).
  • Versioning should be thought through: it would be helpful if pyxnat versions somehow indicated the supported XNAT version.
  • The ability to freeze and commit at once local changes would be useful.
  • SPDY might help with speed.
  • No labels

5 Comments

  1. Rick Herrick

    What does it take to get pyXnat to 1.0?

    • We need a list of requirements for pyXnat to become a 1.0.
    • Why did Yannick not think that it was 1.0?

    pyXnat versioning should track XNAT versioning, so when we release bring it into accord. If the pyXnat version is not the same as XNAT, it at least needs a matrix of tested known-good XNAT versions so that each version of the tool knows its requirements.

    Should we use git or hg? Migrating over to bitbucket.org would make sense to keep our admin roles unified, but hg isn't necessarily required.

    Christian has a sweet pyXnat pipeline launcher and extended pyXnat implementation.

  2. Scott Burns

    Certainly no disrespect to Yannick, but I think all pyxnat users want the package to be less of a pet project and more of an officially supported API to XNAT.

    As far as versioning goes, does XNAT have a rest call to get that instances' API version? Knowing the particular xnat's version could let pyxnat validate/optimize calls and decouple a particular xnat system from python client code. 

    If we're dreaming, pre-building lxml against the major OSs would be great too.

     

    1. Rick Herrick

      The official support concern is really the biggest issue with bringing pyXnat into the NRG stable. Yannick's already put plenty of time and effort into pyXnat so taking on the burden of maintenance here is both reasonable and practical. The level of reliance that the community has on pyXnat as a dependency makes that even more critical.

      As for the server version, yes, there's a version call:

      http://server/data/version

      Of course if you have any app context path for your application, add that as appropriate.

      We'll put the lxml on the backlog.

  3. Christian Haselgrove

    Pre-building lxml would be great – I did discuss with Yannick at one point replacing lxml and httplib2 with standard python libraries (to paraphrase Stephen Hawking: for each dependency not in the standard library, we lose 50% of our remaining users).  Pre-building lxml could save some work, but I have this nagging feeling there was some issue with including it in the distribution.  License?  Python installers' handling of compiled modules?  In any case, I'll add it to the do-list.

    That's right, I paraphrased Stephen Hawking.  I'm an egomaster high-scorer.

  4. Scott Burns

    I'm not sure about the xml lib that ships with python, but the http and url libs (httplib/urllib/urllib2) that ship by default are terrible. 

    Both

    > pip install httplib2

    > pip install pyxnat

    (generally) work no problem because they're both pure python. lxml is the hard part because it requires a compiler and libxml2. It is BSD licensed though so maybe we can think about bundling it?