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
