Carl, This is my answer to your poll request, not that I understand anything yet. I worked my way through a Windows install over the weekend, so my concepts may not the least bit valid for Linux or for your discussions as developers.
My understanding as Ed explained it to me is that the dabo directory is actually a module that Python imports. And if that directory is placed inside site-packages, no dabo.pth is even needed. And for me, any step that can be skipped is one that should be skipped, so I put dabo in site-packages. As he explained further, dabodemo and daboide contain actual apps that have been developed using the stuff inside the dabo directory. So I am thinking of the dabo directory, sitting in the Python site-packages, as a run-time engine. And since I wouldn't put a VFP app anywhere near the VFP directory, I figured I wouldn't put dabodemo or daboide with the dabo "engine" stuff. So I put them as C:\dabodemo & C:\daboide. Maybe kind of like installing the VFP runtimes somewhere and then putting your app & data somewhere else ? On the other hand, I'd expect that the IDE would be considered a core part of the overall development engine, so I can see the reason to keep things close. Ed's response to me was: 1. There are two completely separate things: the Dabo framework, and all the stuff we built with the Dabo framework. The framework needs to be installed in site-packages, either directly or indirectly through the use of a 'dabo.pth' file. This way Python knows what you mean when your code says 'import dabo'. 2. The demo and ide directories should *not* go in site-packages. They are a collection of apps built with Dabo for you to either learn about Dabo (demo), or work with it (ide). They should be installed somewhere that is convenient for you - it really doesn't matter. Maybe I messed up bigtime, but it works for me for now. Chuck On 4/8/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > I am gong to overhaul some of the setup docs. I don't like any of the > suggested > names for the dabo home dir (dabo and projects.) > > dabo makes sense, but then the classes end up in dabo/dabo, which can lead to > confusion when someone says "the dabo dir." I considered renaming it dac > (dabo > abstract classes) and making the docs show how to link/path it into site > packages such that the "import dabo" command would still work, but decided > that > was worse than dabo/dabo. > > > [EMAIL PROTECTED]:~$ find ./ -name dabo -type d > ./src/projects/dabo > > ~/dev/apps/ is where my apps go > > > [EMAIL PROTECTED]:~$ find ./ -name dabo -type d > ./dev/dabo > ./dabo > ./dabo/carl/dabo > ./dabo/carl/dabo/dabo > ./dabo/carl/dabo.foo/dabo > ./dabo/carl/dabo.bar/dabo > ./dabo/trunk/dabo > ./dabo/trunk/dabo/dabo > > ./dev/dabo is where my apps go. > > I am wondering if anyone has come up with something better? > > Carl K > > _______________________________________________ > Post Messages to: [email protected] > Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users > Searchable Archives: http://leafe.com/archives/search/dabo-users > This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED] > _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
