Hi Nuno,

No examples yet on SPDX 2.0.  We've been discussing some kind of "plugfest"
where we could try interchanging SPDX documents between different parsers
for SPDX 2.0.  Will likely happen at or after LinuxCon U.S.  You should see
more info on this mailing list as we get closer.

Gary

> -----Original Message-----
> From: [email protected] [mailto:spdx-tech-
> [email protected]] On Behalf Of Nuno Brito
> Sent: Friday, May 9, 2014 6:48 AM
> To: [email protected]
> Cc: [email protected]; Philippe Ombredanne
> Subject: Re: GSoC python binding project - Fw: Re: Google Summer of
> Code 2014: Ahmed's project
> 
> Hi,
> 
> > should be feature-complete versus existing work; also, while it is
> > nice that Ahmed will continue after the program finishes, and/or
> > others will pick up the maintainence of such work, if it shares some
> > with a larger bulk there is a better chance of that happening -
> > otherwise it is just a few months of work gradually bit-rotting and
> > abandoned in a few years' time. I am okay
> 
> I agree. At this point is already difficult to find voluntaries for the
> current base in Java but hopefully the new code in Python won't be too
> depending on external libraries, making it easier for integration with
> Jython and other platforms when necessary. Perhaps a good idea to keep
> the code interfacing with these dependencies isolated.
> 
> During this month I'm putting together on github a folder with assorted
> SPDX documents from different sources to run stress tests on the
> parsers. Should help to highlight what needs to be corrected or handled
> by the Python code.
> 
> Anyone knows if file examples for SPDX 2.0 are already available?
> 
> 
> With kind regards,
> Nuno Brito
> 
> ---
> spdx: http://triplecheck.de/download
> phone:  +49 615 146 03187
> 
> On 2014-05-09 14:51, Hin-Tak Leung wrote:
> > Hi,
> >
> > I didn't look very hard, but I haven't seen any postings of Ahmed in
> > spdx-tech's archive.
> > In any case, that's not optional - all communications (and *regular*
> > ones as that) should CC spdx-tech.
> >
> > I am not too concerned about python 2.7 vs python 3 - most of the
> > world is still operating at 2.7, but forward porting, one-off via the
> > 2to3 script, is relatively straight-forward; and backward
> > compatibility, at least to the last few minor releases of 2.7 or even
> > 2.6, can be achived via "from __future__ import *".
> > It is possible to write python code that works identically under
> > 2.7 and 3. That's not really a concern - we'll cross that bridge when
> > we need to, when we have some code to discuss on.
> >
> > The jython + existing java code ideas serves a few purposes - the
> > python binding should be feature-complete versus existing work; also,
> > while it is nice that Ahmed will continue after the program finishes,
> > and/or others will pick up the maintainence of such work, if it
> shares
> > some with a larger bulk there is a better chance of that happening -
> > otherwise it is just a few months of work gradually bit-rotting and
> > abandoned in a few years' time. I am okay with it sharing some work
> > with another language-binding project - otherwise you get two sets of
> > bugs and two sets of possibly incompatible implementations to worry
> > about; one of them gradually bit-rotting and go unmaintained.
> > I won't insist on it; it is just a possibility that should be
> explored.
> >
> > It is not entirely unthinkable doing java code as a shared library -
> I
> > know of one software which is fairly successful in its own way(pdftk)
> > and nobody even noticed that part of it is in a java-based gcj
> > compiled shared library.
> >
> > Creating a c-binding (whether it is based on the java code or new) is
> > also a good way of ensuring new languages can be supported quickly; I
> > don't know how the GO-binding project is going to go about it, but
> > there is some shared work that can go in that direction.
> >
> > Hin-Tak
> >
> > --------------------------------------------
> > On Fri, 9/5/14, Philippe Ombredanne <[email protected]> wrote:
> >
> >  Subject: Re: GSoC python binding project - Fw: Re: Google Summer of
> > Code 2014: Ahmed's project
> >  To: [email protected]
> >  Cc: "[email protected]" <[email protected]>, "ahi"
> > <[email protected]>, "Philippe Ombredanne"
> > <[email protected]>, "Nuno Brito" <[email protected]>
> >  Date: Friday, 9 May, 2014, 9:08
> >
> >  On Fri, May 9, 2014 at
> >  1:14 AM, Hin-Tak Leung
> >  <[email protected]>
> >  wrote:
> >  > Hi Ahmed,
> >  >
> >  Administratively, I think we should also estabish a few  ground
> > rules:
> >  > - you should register
> >  some public source-code hosting facility - github, etc - as  soon  >
> > as possible, for show-casing your  up-coming work and aiding
> > discussion  >  and collaboration.
> >
> >  Amhed:
> >  Gary can set you up on
> >  git.spdx.org alright. And you can mirror it  elsewhere as you
> please.
> >  And
> >  communication-wise, all the communication should go through  the
> > spdx-tech list.
> >
> >  [....]
> >
> >  > As
> >  for the actual work itself, besides the suggestions I  already made,
> > > following the thought on  the jython + existing java-work approach,
> > there is  > also a somewhat similar route via gcj and  building the
> > java binding into shared libraries  > than going C-binding approach.
> >
> >  Amhed, Hin-Tak:
> >  Anything that would be dependent on bindings  with another SPDX
> > implementation, a Java  implementation or else is IMHO a bad idea.
> >  The goal is to have an implementation in pure  Python, not an
> > interpretation for a certain  interpreter of Python.
> >  In terms of Python
> >  version this should be based on Python 2.7, and  optionally support
> > Python 3.
> >  The Java tests cases might be interesting for  reference and
> possibly
> > for inspiration, but  beyond that the way SPDX is implemented in Java
> > is language and library specific and might not  apply to Python.
> >  Also SPDX is not entirely
> >  about RDF: we have also a name/value pair  serialization format.
> >  With that
> >  said, RDF-wise (for the data model) there are plenty of  Python libs
> > available that grok RDF, RDFlib and  RDFalchemy being among  the most
> > prominent
> >
> >
> >  --
> >  Cordially
> >  Philippe
> >  Ombredanne
> _______________________________________________
> Spdx-tech mailing list
> [email protected]
> https://lists.spdx.org/mailman/listinfo/spdx-tech

_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech

Reply via email to