Re: include.spyce odd path behavior - relative vs absolute paths
"Jason Persampieri" <[email protected]> Wed, 12 Dec 2007 13:40:19 -0500
| Newsgroups | gmane.comp.python.spyce.general |
|---|---|
| Message-ID | <[email protected]> |
--===============1596454464== Content-Type: multipart/alternative; boundary="----=_Part_7617_16875446.1197484819777" ------=_Part_7617_16875446.1197484819777 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess the core problem is that the python code (eg *execfile*) and spyce code (eg *include.spyce*) seem to use two different working directories. If these could be sync'ed, it would feel smoother. Obviously, this would break too much other code to consider... ah well :) _jason On Dec 11, 2007 3:11 PM, Jonathan Ellis <[email protected]> wrote: > For most use cases it's more convenient to treat the path as a "path" > the way the browser would interpret it. That's the only reason it works > the way it does. If I were to revisit this for spyce 2.2 I would > probably do it the way you suggest and just have the user use > util.url2file if they want the docroot-relative path, but in earlier > versions it's enough extra verbosity to import spyceUtil and do that > that it wasn't worth it. > > -Jonathan > > On Tue, 11 Dec 2007 14:44:25 -0500, "Jason Persampieri" > <[email protected]> said: > > Howdy folks. Spyce newbie here. > > > > I have noticed an oddity in the *include.spyce* behavior. > > > > If the argument is a relative path - *include.spyce('../include.spy')* - > > everything works fine. > > > > But if I pass an absolute path - > > *include.spyce('/cluster/home/user/public_html/share/include.spy') > > *- it looks like spyce prepends the spyce home directory (which in this > > case > > is the same as the http home) on to the path - * spyceNotFound: > > spyceNotFound exception: could not find > > "/common/www/html/cluster/home/user/public_html/share/include.spy" > > > > *While the absolute path behavior seems consistent with the > > documentation, > > this is incredibly odd. If I specify an absolute path, shouldn't it > > assume > > I'm pointing to exactly what I want? > > > > this whole thing is especially annoying since I need to *execfile *a > > file > > in the same directory (which *only* takes absolute paths seemingly) and > > hence need to keep both a relative and absolute path reference. Piddly > > to > > be sure, but annoying. > > > > That said, Spyce is really rocking my world, and is *exactly* the right > > solution for my project. > > > > Jason Persampieri > > Programmer > > Boston College Bioinformatics Dept. > ------=_Part_7617_16875446.1197484819777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess the core problem is that the python code (eg <i>execfile</i>) and spyce code (eg <i>include.spyce</i>) seem to use two different working directories. If these could be sync'ed, it would feel smoother. Obviously, this would break too much other code to consider... ah well :) <br><br>_jason<br><br><div class="gmail_quote">On Dec 11, 2007 3:11 PM, Jonathan Ellis <<a href="mailto:[email protected]">[email protected]</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> For most use cases it's more convenient to treat the path as a "path"<br>the way the browser would interpret it. That's the only reason it works<br>the way it does. If I were to revisit this for spyce 2.2 I would<br>probably do it the way you suggest and just have the user use<br>util.url2file if they want the docroot-relative path, but in earlier<br>versions it's enough extra verbosity to import spyceUtil and do that <br>that it wasn't worth it.<br><font color="#888888"><br>-Jonathan<br></font><div><div></div><div class="Wj3C7c"><br>On Tue, 11 Dec 2007 14:44:25 -0500, "Jason Persampieri"<br><<a href="mailto:[email protected]"> [email protected]</a>> said:<br>> Howdy folks. Spyce newbie here.<br>><br>> I have noticed an oddity in the *include.spyce* behavior.<br>><br>> If the argument is a relative path - *include.spyce ('../include.spy')* -<br>> everything works fine.<br>><br>> But if I pass an absolute path -<br>> *include.spyce('/cluster/home/user/public_html/share/include.spy')<br>> *- it looks like spyce prepends the spyce home directory (which in this <br>> case<br>> is the same as the http home) on to the path - * spyceNotFound:<br>> spyceNotFound exception: could not find<br>> "/common/www/html/cluster/home/user/public_html/share/include.spy"<br> ><br>> *While the absolute path behavior seems consistent with the<br>> documentation,<br>> this is incredibly odd. If I specify an absolute path, shouldn't it<br>> assume<br>> I'm pointing to exactly what I want? <br>><br>> this whole thing is especially annoying since I need to *execfile *a<br>> file<br>> in the same directory (which *only* takes absolute paths seemingly) and<br>> hence need to keep both a relative and absolute path reference. Piddly <br>> to<br>> be sure, but annoying.<br>><br>> That said, Spyce is really rocking my world, and is *exactly* the right<br>> solution for my project.<br>><br>> Jason Persampieri<br>> Programmer<br>> Boston College Bioinformatics Dept. <br></div></div></blockquote></div><br> ------=_Part_7617_16875446.1197484819777-- --===============1596454464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace --===============1596454464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Spyce-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spyce-users --===============1596454464==--