Danek, Thanks for your feedback.
One thing, I just installed latest OSOL (2009.06) and it does have cherrypy! And it does appear in the /release repository as well (http://pkg.opensolaris.org/release/en/search.shtml?token=python&action=Search). Wonder how it made it to /release without getting ARC approval!? I will however remove it my dependency list. -manjunath Danek Duvall wrote: > Manjunath Basappa wrote: > > >> I will list the following dependencies: >> >> SUNWPython at 2.4.4,5.11-0.111:20090508T152730Z >> SUNWPython26 at 2.6.1,5.11-0.111:20090508T152901Z >> SUNWpython-cherrypy at 3.1.1,5.11-0.111:20090508T163103Z >> > > Sounds good, though a) I'm not sure what the ARC will think of dependencies > specified in OpenSolaris terms and b) cherrypy is still not ARCed in any > way, and so not suitable for this project to depend on. > > >>> If the web engine is pluggable, is it appropriate to have a hard dependency >>> on one of them? >>> >> But, routes would not work without some version of python, either >> 2.4 or 2.6. That is the only hard dependency. CherryPy, is not a >> hard dependency. >> > > By "hard", I mean that you'll be specifying it in your package > dependencies; that the routes packages cannot be installed without having > cherrypy installed first. If that's not the case (and it sounds like it's > not), then there's no need to list cherrypy as an imported interface. It > will simply be used if that's what the routes developer chooses to use. > > >>> If you're delivering both Python 2.4 and Python 2.6 modules in the same >>> package, which version of Python does the package depend on? >>> >> Ok, agreed. I will deliver the following two packages: >> SUNWpython24-routes >> SUNWpython26-routes >> > > Sounds fine to me. > > >> I thought, since we are just exposing modules and classes to a web >> framework, they are not public interfaces...it becomes an active exposed >> interface if an instance of a class is created, I thought.. >> > > An interface needn't be a user interface. It is any interface that a > project chooses to expose to the outside world. It can be a commandline, a > set of functions, an environment variable -- anything that another project > might choose to use. > > >> Ok, here are the interfaces or modules exposed to any python web framework: >> >> routes >> Provides common classes and functions most users will want access to. >> routes.base >> Route and Mapper core classes >> routes.middleware >> Routes WSGI Middleware >> routes.threadinglocal >> routes.util >> Utility functions for use in templates / controllers >> > > This sounds like a reasonable list. The full list of functions, classes, > and methods should be available in the case directory. The output of > "pydoc <module>" for each module is sufficient. I don't think anyone will > bother reviewing them unless you're planning on making a core part of > Solaris depend on this project, but it's good to briefly document what > you're planning on integrating. > > Thanks, > Danek >
