pyrdfa3 repository vs. rdflib's copy of pyrdfa3 about pyrdfa3 HOT 8 CLOSED

Dan,

fair question. The fact is that separate pyRdfa is a matter of history. pyRdfa was originally developed as package on top of RDFLib, and this github repo was used. Then I spent some time migrating the package into RDFLib. However, there are some deployments out there (including my own pyRdfa service on the W3C site) that relies on some of the entry points in this package and, at least for myself, I have never had the time to transform the service at, for example, W3C to use the RDFLib directly. As a consequence, both repos are kept alive insofar as I manage possible bugs on both sides.

But that is indeed confusing if somebody comes in fresh and, actually, those should use the RDFLib version only.

I have modified the Readme file on the repo right now to make this clear. Thanks for bugging me with this!

Ivan

On Aug 13, 2013, at 03:18 , Dan Scott [email protected] wrote:

Repeating the question I just asked on #rdflib - why is there both a top-level pyrdfa3 repository, and a separate copy of pyrdfa3 under the rdflib repository's plugins/parsers subdirectory?

If rdflib was using git submodules to pull in pyrdfa3, that would make some sense; it would enable us to focus on pyrdfa3 as a separate module and hopefully avoid bugs like #7 where rdflib's setup.py handles the 2to3 conversion, while pyrdfa3's own does not.

As an entirely separate copy, however, the risk is that fixes to one repo won't get into the other. And the repos are in fact slightly out of sync with one another (a couple of lines concerning type checking with isinstance()).

—
Reply to this email directly or view it on GitHub.

Ivan Herman
4, rue Beauvallon, clos St Joseph
13090 Aix-en-Provence
France
http://www.ivan-herman.net

from pyrdfa3.

Thanks for clarifying this, shall we also put a deprecation warning in the project description?

As there is a pyRdfa pypi package of version 2.3.7 I think essentially we have two options:

• warn when installing the package:

  A proper way of handling this would be to release a last new version of this package and modify its setup.py so it spits out a huge deprecation warning in case rdflib > 4.0 is present? We could even do this bidirectional and in rdflib's setup.py check for the presence of pyRDFa and spit out a warning there as well.

• deprecate the package: (my favorite option):

  The same as warn but make the new version "empty" and just depend on a current version of rdflib to be installed. For backwards compatibility people could still explicitly ask for old versions of pyrdfa, but new users wouldn't run into this trap anymore.

• continue:

  continue its development and externalize pyRDFa from core rdflib again (i'd vote against this as i consider RDFa as a core component of rdflib)

from pyrdfa3.

On Aug 13, 2013, at 10:38 , Jörn Hees [email protected] wrote:

Thanks for clarifying this, shall we also put a deprecation warning in the project description?

Yes, that is probably a good idea...

As there is a pyRdfa pypi package of version 2.3.7 I think essentially we have two options:

There is, but I do not own it, nor do I actually know how to handle it (I must admit that I am usually old-skool and I rarely use pypi to install things:-(

• warn when installing the package:

A proper way of handling this would be to release a last new version of this package and modify its setup.py so it spits out a huge deprecation warning in case rdflib > 4.0 is present? We could even do this bidirectional and in rdflib's setup.py check for the presence of pyRDFa and spit out a warning there as well.

That can be done. As for the inverse, I would not go there. Again, there are deployments out there that do use the separate package but nevertheless use the latest version of rdflib; that would be a bit of a pain.

• deprecate the package: (my favorite option):

The same as warn but make the new version "empty" and just depend on a current version of rdflib to be installed. For backwards compatibility people could still explicitly ask for old versions of pyrdfa, but new users wouldn't run into this trap anymore.

I am not very experienced with github, I am not sure what it would mean in practice for people. I think that an explicit warning for deprecation should be enough, essentially the way it is now

• continue:

continue its development and externalize pyRDFa from core rdflib again (i'd vote against this as i consider RDFa as a core component of rdflib)

I would certainly be opposed to that. As I said, the separate package has an importance for the few deployments out there (including mine:-), ie, I will keep it mostly up-to-date for errors, but the future is certainly having pyRdfa (and the sister package for microdata!) as integral part of rdflib.

Ivan

—
Reply to this email directly or view it on GitHub.

Ivan Herman
4, rue Beauvallon, clos St Joseph
13090 Aix-en-Provence
France
http://www.ivan-herman.net

from pyrdfa3.

As I rdflib developer - I usually just pretend that this project does not exist and leave Ivan to sort it out :)

I would simply try to get the pyrdfa package removed from pypi, very few people should have any reason to install this directly.

Otherwise I would make the README into a markdown file (.md), so that you can get a bigger font for the warning that this is not the right way to get rdfa in python :)

from pyrdfa3.

Thanks to all of you for being so receptive, understanding, and responsive to a new adopter of rdflib & pyrdfa! I concur with Gunnar's "remove pyrdfa from pypi entirely" opinion, for what that's worth.

Perhaps it would make sense to delete the "pyrdfa3" and "pyRdfa" repositories from the http://github.com/rdflib organization, too? Although the warning in the README certainly helps :)

from pyrdfa3.

On Aug 13, 2013, at 20:04 , Dan Scott [email protected] wrote:

Thanks to all of you for being so receptive, understanding, and responsive to a new adopter of rdflib & pyrdfa! I concur with Gunnar's "remove pyrdfa from pypi entirely" opinion, for what that's worth.

Perhaps it would make sense to delete the "pyrdfa3" and "pyRdfa" repositories from the http://github.com/rdflib organization, too? Although the warning in the README certainly helps :)

I would prefer not to. There are existing deployments who may rely on my updates, and moving a repository is a drag on all of them.

Ivan

—
Reply to this email directly or view it on GitHub.

Ivan Herman
4, rue Beauvallon, clos St Joseph
13090 Aix-en-Provence
France
http://www.ivan-herman.net

from pyrdfa3.

On Aug 13, 2013, at 19:46 , Gunnar Aastrand Grimnes [email protected] wrote:

As I rdflib developer - I usually just pretend that this project does not exist and leave Ivan to sort it out :)

I would simply try to get the pyrdfa package removed from pypi, very few people should have any reason to install this directly.

Otherwise I would make the README into a markdown file (.md), so that you can get a bigger font for the warning that this is not the right way to get rdfa in python :)

Added an .md version...

Ivan

—
Reply to this email directly or view it on GitHub.

Ivan Herman
4, rue Beauvallon, clos St Joseph
13090 Aix-en-Provence
France
http://www.ivan-herman.net

from pyrdfa3.

Overtaken by events. The latest evolution of RDFLib is to remove the RDFa parser from the core distribution, and this code is meant to be the one used as a plugin.

from pyrdfa3.