1. fanstatic
  2. fanstatic
  3. fanstatic
  4. Issues
Issue #31 resolved

API in __init__.py: library_registry is in the way when importing Library

Jan-Jaap Driessen
created an issue

This issue is related to <<issue 4>> and <<issue 15>>.

When you run bin/prepare in js.jqueryui, you get an error from the library_registry. All I wanted to do in js.jquery is import Library and Resource(Inclusion).

I tried to rewrite js.jqueryui to avoid this behavior, but could not get far before hitting a wall.

I fixed this by removing the imports of library_registry, LibraryRegistry and Fanstatic from init.py and rewriting some imports in other modules. The tests and bin/prepare in js.jquery work again after this change. I didn't check this in yet, as the changes are trivial but need to be discussed.

In my opinion, the init.py exposes too much. The library_registry is only relevant to the wsgi components and could be imported from the registry module. The Fanstatic wsgi component is already exposed through an entry_point and could be removed from the init.py.

How do you think about bringing back the API to a minimum?

Comments (7)

  1. faassen

    I do think we should expose the WSGI components through init.py, as it's hardly unusual to want to use a WSGI component directly in Python code.

    I also think library_registry should be exposed in init.py; you make use of this in the zope integration for instance, I think, and this is therefore really part of the public API.

    I'm trying to understand the nature of the problem with js.jqueryui; unfortunately you didn't include the traceback.

    I'm really curious why we're still using 'prepare' at all. I thought we had agreed we'd much simplify these packages and just check in the javascript code directly into the project instead. We had 'prepare' as we had to deal with licensing concerns when checking into svn.zope.org, but that has gone away. I think as a tool for automatically maintaining such packages prepare has serious issues; among others the fragile and really rather large "prepare.py" code. If we want to go that way, couldn't we think about a tool to automatically create whole js.* packages instead?

  2. Jan-Jaap Driessen reporter

    I'm trying to understand the nature of the problem with js.jqueryui; unfortunately you didn't include the traceback.

    You can reproduce by running the buildout of js.jqueryui and running bin/prepare.

    I'm really curious why we're still using 'prepare' at all.

    Same here. The next release of js.jqueryui will probably be just downloading the sources, unzipping, some diffing, maybe add a Resource or two to init.py . The result of the current prepare script needs to be hand tuned anyway.

    The prepare script is based on hurry.yui/js.yui, where prepare introspects the YUI hierarchy and mimicks this in the python code.

  3. faassen

    Right, I can see the use case for YUI, but not for most packages which involve just a few files and we don't have a machine-readable version of dependencies anyway.

  4. Jan-Jaap Driessen reporter

    The library_registry is in the way when running the js.yui tests:

    """ /usr/lib/python2.6/doctest.py:1248: in run

    compileflags, 1) in test.globs

    <doctest test_yui.txt[0]>:1: in <module>

    ???

    js/yui/init.py:1: in <module>

    from fanstatic import Library, Resource

    src/fanstatic/fanstatic/init.py:9: in <module>

    from fanstatic.registry import library_registry, LibraryRegistry

    src/fanstatic/fanstatic/registry.py:36: in <module>

    library_registry = LibraryRegistry(get_libraries_from_entry_points())

    src/fanstatic/fanstatic/registry.py:33: in get_libraries_from_entry_points

    libraries.append(entry_point.load())

    /home/jdriessen/.buildout/eggs/setuptools-0.6c12dev_r85381-py2.6.egg/pkg_resources.py:1959: in load

    raise ImportError("%r has no %r attribute" % (entry,attr))

    E ImportError: <module 'js.yui' from '/home/jdriessen/projects/bitbucket/js.yui/js/yui/init.pyc'> has no 'library' attribute """

    When I remove the 'yui' fanstatic entry_point in the setup.py, re-run buildout and run the tests, the tests pass.

  5. Log in to comment