e.g, In an ideal world, I'd like something like /application/example_data/ --> example_one --> example_two
~/.application/data --> project_one --> project_two To look like data/ --> example_one (read only) --> example_two (read only) --> project_one --> project_two But I'm thinking it's a bad concept now. On Mon, Jan 13, 2014 at 8:52 PM, Tennessee Leeuwenburg < [email protected]> wrote: > I imagine wanting to supply multiple data paths, and want a lazy way to > write something that just munges them together into a single list of > available projects. Ideally. Falling back to only allowing one configurable > directory is reasonable. I can just make it easy to deploy the demo files > into a new workspace rather than having them included by the code directly. > > > On Mon, Jan 13, 2014 at 8:48 PM, Daniel Alan Miller < > [email protected]> wrote: > >> Given a specified folfer hierarchy why not just use the files you already >> have for the data, if I'm understanding correctly? >> >> An instance of your application can run and anything within the directory >> path supplied when you run the application that fits the specification be >> (Monitored? Used? Consumed?) by the application. >> On Jan 13, 2014 8:13 PM, "Tennessee Leeuwenburg" <[email protected]> >> wrote: >> >>> Hey, >>> >>> A question for the peanut gallery... >>> >>> I'm writing a flask/bootstrap web app (not open sourced as yet) for >>> doing some scientific processing in a pipeline data processing methodology. >>> I want to write an example pipeline, but then have the app be deployable in >>> user space and use either a configured directory or a dot-prefix directory >>> for the data of that particular instance of the app. I had imagined this >>> could be like a "layer" over the top of the core application layer, so that >>> users could have their projects side-by-side with the core application >>> examples. >>> >>> I'm now thinking maybe that's a bad idea, and it would be better just to >>> copy the sample projects into the users workspace. >>> >>> In fact I think I've pretty much convinced myself given it took just one >>> sentence to say and seems immediately clear. >>> >>> Are there any other paradigms in web apps for managing the application >>> state (other than packing everything into a database)? The data here exists >>> naturally in a fundamentally file-based paradigm, so I think it makes sense >>> to continue that mainly. >>> >>> Cheers, >>> -Tennessee >>> >>> -- >>> -------------------------------------------------- >>> Tennessee Leeuwenburg >>> http://myownhat.blogspot.com/ >>> "Don't believe everything you think" >>> >>> _______________________________________________ >>> melbourne-pug mailing list >>> [email protected] >>> https://mail.python.org/mailman/listinfo/melbourne-pug >>> >>> >> _______________________________________________ >> melbourne-pug mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/melbourne-pug >> >> > > > -- > -------------------------------------------------- > Tennessee Leeuwenburg > http://myownhat.blogspot.com/ > "Don't believe everything you think" > -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
