From: Jonatan L. <li...@ky...> - 2006-01-24 12:57:37
|
I just came up with an idea about how one can solve the issue with relocatable LibDirs and how to find them. Yes I know that 0install injector is one solution, but what if you don't use 0install? =) Idea: since an appdir (and a libdir) can find $XDG_CONFIG_HOME, then also $XDG_CONFIG_HOME can find a certain libdir. It's as simple as letting the LibDir, when clicked, write it's location to $XDG_CONFIG_HOME/domain/LibName/path. (also popping up an info box saying "LibName is now registered"). All apps looking for a perticular LibDir can now just look there! ROX-Lib2 could be changed to use this method, findrox.py locates Rox-Lib2 by looking in $XDG_CONFIG_HOME/rox.sourceforge.net/ROX-Lib2/path and then ROX-Lib2 can contain nice helper functions to find other libdirs, etc... for example: rox.locateLibDir(domain,LibName,version) would look in $XDG_CONFIG_HOME/domain/LibName/path and see if it actually points to a valid libdir with at least the given version, and if so add it to sys.path. If this fails, it would try 0launch (asking first, imho) or else display a nice error message. The install instructions for a LibDir would be really simple: Drop it somewhere and click on it. A very important thing is that this could also be used for an AppDir (or LibDir) to find another AppDir. (Actually there wouldn't really be any difference between an AppDir and LibDir, it's just conceptually...) For example, I would like my RoxDAO cd-writing software to be able to find the Mp3Ogg2Wav utility to automatically convert mp3 files to wav so that cdrdao can handle it. (now it needs Mp3Ogg2Wav to be installed in same dir as RoxDAO). What do you think? /Jonatan -=( http://kymatica.com )=- |
From: Thomas L. <ta...@gm...> - 2006-01-25 09:40:09
|
On 1/24/06, Jonatan Liljedahl <li...@ky...> wrote: > I just came up with an idea about how one can solve the issue with > relocatable LibDirs and how to find them. Yes I know that 0install > injector is one solution, but what if you don't use 0install? =3D) > > Idea: since an appdir (and a libdir) can find $XDG_CONFIG_HOME, > then also $XDG_CONFIG_HOME can find a certain libdir. > It's as simple as letting the LibDir, when clicked, write it's location > to $XDG_CONFIG_HOME/domain/LibName/path. (also popping up > an info box saying "LibName is now registered"). > All apps looking for a perticular LibDir can now just look there! > > ROX-Lib2 could be changed to use this method, findrox.py locates > Rox-Lib2 by looking in > $XDG_CONFIG_HOME/rox.sourceforge.net/ROX-Lib2/path and then ROX-Lib2 > can contain nice helper functions to find other libdirs, etc... for > example: rox.locateLibDir(domain,LibName,version) Good idea. And, to make the library name really unique, you could add a 'year' argument as well. Having the domain, year and libName as separate arguments is a bit messy, though. It might be neater to combine them into a single string which you can use to refer to the library. This is how w3c uses namespaces, for example. The you could do something like: import findlib findlib.resolve('http://rox.sourcefoge.net/2005/ROX-Lib') import rox > would look in $XDG_CONFIG_HOME/domain/LibName/path and see if it > actually points to a valid libdir with at least the given version, and if= so > add it to sys.path. If this fails, it would try 0launch (asking first, im= ho) or > else display a nice error message. One problem with having the code in Python is that we can't reuse it with other programs (e.g., C, PERL, Ruby ROX applications). Since you're just changing PYTHONPATH, how about using a separate executable? Then the AppRun for a program would just be: #!/bin/sh APP_DIR=3D`dirname "$0"` exec rox-launch --with-library http://rox.sourceforge.net/2005/ROX-Lib "$@" Actually, if you have a lot of libraries and version numbers then the command-line could get quite long. Maybe we should list them all in a file, and just refer to that. XML is a good format for these kinds of things, since it will let us add extra information like which PATH variable to change. Then we'd have: #!/bin/sh APP_DIR=3D`dirname "$0"` exec rox-launch ./requiredLibraries.xml "$@" requiredLibraries.xml would list everything we need. E.g.: <requiredLibraries> <requires library=3D'http://rox.sourceforge.net/2005/ROX-Lib'> <environment insert=3D"ROX-Lib2/python" name=3D"PYTHONPATH"/> </requires> </requiredLibraries> > The install instructions for a LibDir would be really simple: Drop it > somewhere and click on it. To save copying the code to do the registration into every app, we could add that to rox-launch too. Then ROX-Lib's AppRun would just be: rox-launch --add-library $APPDIR To let rox-launch warn about overwriting a newer version, you might want to point it at the AppInfo.xml file so it can check the version too: rox-launch --add-library "$APPDIR/AppInfo.xml" Of course, we don't want to lose Zero Install users, so we should register the injector feed at the same time: 0launch --add-feed "$APPDIR/ROX-Lib.xml" > A very important thing is that this could also be used for an AppDir > (or LibDir) to find another AppDir. (Actually there wouldn't really be > any difference between an AppDir and LibDir, it's just conceptually...) Good thinking. 'library' isn't a good name. How about calling them 'interfaces' instead? Then the names would be http://rox.sourceforge.net/2005/interfaces/ROX-Filer, etc. > For example, I would like my RoxDAO cd-writing software to be able to > find the Mp3Ogg2Wav utility to automatically convert mp3 files to wav > so that cdrdao can handle it. (now it needs Mp3Ogg2Wav to be installed > in same dir as RoxDAO). > > What do you think? If only we already had a way to do all this... -- Dr Thomas Leonard=09=09http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Jonatan L. <li...@ky...> - 2006-01-25 22:05:12
|
On Wed, 25 Jan 2006 09:40:03 +0000 Thomas Leonard <ta...@gm...> wrote: > On 1/24/06, Jonatan Liljedahl <li...@ky...> wrote: > > I just came up with an idea about how one can solve the issue with > > relocatable LibDirs and how to find them. Yes I know that 0install > > injector is one solution, but what if you don't use 0install? =) > > > > Idea: since an appdir (and a libdir) can find $XDG_CONFIG_HOME, > > then also $XDG_CONFIG_HOME can find a certain libdir. > > It's as simple as letting the LibDir, when clicked, write it's > > location to $XDG_CONFIG_HOME/domain/LibName/path. (also popping up > > an info box saying "LibName is now registered"). > > All apps looking for a perticular LibDir can now just look there! > > > > ROX-Lib2 could be changed to use this method, findrox.py locates > > Rox-Lib2 by looking in > > $XDG_CONFIG_HOME/rox.sourceforge.net/ROX-Lib2/path and then ROX-Lib2 > > can contain nice helper functions to find other libdirs, etc... for > > example: rox.locateLibDir(domain,LibName,version) > > Good idea. And, to make the library name really unique, you could add > a 'year' argument as well. What's the point with the year argument? Is that the year of the current version of the software or the year of the very first official version? or maybe it's the current year? > Having the domain, year and libName as separate arguments is a bit > messy, though. It might be neater to combine them into a single string > which you can use to refer to the library. This is how w3c uses > namespaces, for example. The you could do something like: > > import findlib > findlib.resolve('http://rox.sourcefoge.net/2005/ROX-Lib') > import rox > > > would look in $XDG_CONFIG_HOME/domain/LibName/path and see if it > > actually points to a valid libdir with at least the given version, > > and if so add it to sys.path. If this fails, it would try 0launch > > (asking first, imho) or else display a nice error message. > > One problem with having the code in Python is that we can't reuse it > with other programs (e.g., C, PERL, Ruby ROX applications). I was thinking that it would be very easy to write similar code in the other languages rox libraries. Just checking for a path in $XDG_CONFIG_HOME/domain/Name/path would even be simple enough for a couple of lines of shellcode. How does 0install injector handle other languages than Python? > Since > you're just changing PYTHONPATH, how about using a separate > executable? Then the AppRun for a program would just be: > > #!/bin/sh > APP_DIR=`dirname "$0"` > exec rox-launch --with-library > http://rox.sourceforge.net/2005/ROX-Lib "$@" > > Actually, if you have a lot of libraries and version numbers then the > command-line could get quite long. Maybe we should list them all in a > file, and just refer to that. XML is a good format for these kinds of > things, since it will let us add extra information like which PATH > variable to change. Then we'd have: > > #!/bin/sh > APP_DIR=`dirname "$0"` > exec rox-launch ./requiredLibraries.xml "$@" > > requiredLibraries.xml would list everything we need. E.g.: > > <requiredLibraries> > <requires library='http://rox.sourceforge.net/2005/ROX-Lib'> > <environment insert="ROX-Lib2/python" name="PYTHONPATH"/> > </requires> > </requiredLibraries> > > > The install instructions for a LibDir would be really simple: Drop > > it somewhere and click on it. > > To save copying the code to do the registration into every app, we > could add that to rox-launch too. Then ROX-Lib's AppRun would just be: > > rox-launch --add-library $APPDIR > > To let rox-launch warn about overwriting a newer version, you might > want to point it at the AppInfo.xml file so it can check the version > too: > > rox-launch --add-library "$APPDIR/AppInfo.xml" > > Of course, we don't want to lose Zero Install users, so we should > register the injector feed at the same time: > > 0launch --add-feed "$APPDIR/ROX-Lib.xml" > > > A very important thing is that this could also be used for an AppDir > > (or LibDir) to find another AppDir. (Actually there wouldn't really > > be any difference between an AppDir and LibDir, it's just > > conceptually...) > > Good thinking. 'library' isn't a good name. How about calling them > 'interfaces' instead? Then the names would be > http://rox.sourceforge.net/2005/interfaces/ROX-Filer, etc. > > > For example, I would like my RoxDAO cd-writing software to be able > > to find the Mp3Ogg2Wav utility to automatically convert mp3 files > > to wav so that cdrdao can handle it. (now it needs Mp3Ogg2Wav to be > > installed in same dir as RoxDAO). > > > > What do you think? > > If only we already had a way to do all this... I see that you're ironic. Would you like to explain how 0install injector could be used for this, without network access and without having the applications and libraries in a cache? (no wrappers) Regarding the "registration" of downloaded and manually installed libraries, does ROX-Lib do this when clicked? /Jonatan -=( http://kymatica.com )=- |
From: Thomas L. <ta...@ec...> - 2006-01-26 19:01:44
|
On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: > On Wed, 25 Jan 2006 09:40:03 +0000 > Thomas Leonard <ta...@gm...> wrote: > >> On 1/24/06, Jonatan Liljedahl <li...@ky...> wrote: >> > Idea: since an appdir (and a libdir) can find $XDG_CONFIG_HOME, then >> > also $XDG_CONFIG_HOME can find a certain libdir. It's as simple as >> > letting the LibDir, when clicked, write it's location to >> > $XDG_CONFIG_HOME/domain/LibName/path. (also popping up an info box >> > saying "LibName is now registered"). All apps looking for a perticular >> > LibDir can now just look there! >> Good idea. And, to make the library name really unique, you could add a >> 'year' argument as well. > > What's the point with the year argument? Is that the year of the current > version of the software or the year of the very first official version? or > maybe it's the current year? Generally, the year you created the name. It's optional, but it can help to keep your namespaces under control, since you only have to avoid accidentally using the same name twice in one year. The downside is that it can confuse people about what it means. For example, XHTML documents start with this, where '1999' is the year that that version of the XHTML standard was created: <html xmlns="http://www.w3.org/1999/xhtml"> >> import findlib >> findlib.resolve('http://rox.sourcefoge.net/2005/ROX-Lib') import rox >> >> One problem with having the code in Python is that we can't reuse it >> with other programs (e.g., C, PERL, Ruby ROX applications). > > I was thinking that it would be very easy to write similar code in the > other languages rox libraries. Writing code is easy. Keeping it up-to-date is the problem. We already have lots of problems with out-of-date copies of findrox.py, and I don't think the PERL (or Ruby) versions of ROX-Lib are up-to-date either. Likewise, the OptionsBox code in ROX-Filer and ROX-Lib isn't quite the same as the code in ROX-Lib. Generally, having multiple copies of the same code leads to maintenance problems. > Just checking for a path in $XDG_CONFIG_HOME/domain/Name/path would > even be simple enough for a couple of lines of shellcode. And checking the other directories in XDG_CONFIG_DIRS. And the FOO-language bindings would still be using CHOICESPATH when the Python version had switched to D-Conf (or whatever)... > How does 0install injector handle other languages than Python? ROX-Filer isn't written in Python, and that works fine. 0launch is a separate program that sets up the environment and then runs your program. It could be rewritten in C, say, and it wouldn't affect anything (it would just be faster, buggier and harder to maintain). Although if speed's a problem (it isn't for me) there are plenty of opportunities to speed it up without leaving Python. >> > The install instructions for a LibDir would be really simple: Drop it >> > somewhere and click on it. >> >> To save copying the code to do the registration into every app, we >> could add that to rox-launch too. Then ROX-Lib's AppRun would just be: >> rox-launch --add-library "$APPDIR/AppInfo.xml" >> 0launch --add-feed "$APPDIR/ROX-Lib.xml" >> >> > A very important thing is that this could also be used for an AppDir >> > (or LibDir) to find another AppDir. >> >> Good thinking. 'library' isn't a good name. How about calling them >> 'interfaces' instead? Then the names would be >> http://rox.sourceforge.net/2005/interfaces/ROX-Filer, etc. >> >> > What do you think? >> >> If only we already had a way to do all this... > > I see that you're ironic. Would you like to explain how 0install > injector could be used for this, without network access and without > having the applications and libraries in a cache? Why wouldn't it work? I'm not quite sure which bit of it you're trying to avoid, but: - If you have no network connection at all, set the networking mode to 'Offline' and use '0launch --import' to tell it about the interface first (grab a copy from the web and stick it inside the application). We could make this step optional (it might already be; not sure). - If you want to avoid the cache, set the network use to either 'Offline' (never download anything into the cache) or 'Minimal' (only download ROX-Lib if you haven't already clicked on a local version). > Regarding the "registration" of downloaded and manually installed > libraries, does ROX-Lib do this when clicked? No. You have to register it with '0launch --feed ROX-Lib/ROX-Lib.xml'. This assumes you're running it from a terminal and it asks you to confirm currently, but a non-interactive '--add-feed' could be added as well. I was assuming that only developers would want to install libraries manually. Also, if you do this with multiple copies then it registers all of them and lets you choose which one to use (by default, it would use the newest one). To get your desired behaviour, you'd have to remove the previous version when adding a new one, which is easy enough. Probably the best approach is to try it and see what problems there are. -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2006-01-26 19:44:32
|
In <pan...@ec...>, Thomas Leonard wrote: > On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: > > > How does 0install injector handle other languages than Python? > > ROX-Filer isn't written in Python, and that works fine. As long as you use 32-bit x86. I know some packages, including ROX-Filer, have source interfaces, but some don't, and if you have 0install present at all, ROX-Session will try to use it for everything and fail. -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@ec...> - 2006-01-26 19:59:58
|
On Thu, 26 Jan 2006 19:44:28 +0000, Tony Houghton wrote: > In <pan...@ec...>, Thomas Leonard wrote: > >> On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: >> >> > How does 0install injector handle other languages than Python? >> >> ROX-Filer isn't written in Python, and that works fine. > > As long as you use 32-bit x86. Or PPC64. What are you using? > I know some packages, including ROX-Filer, have source interfaces, but > some don't, and if you have 0install present at all, ROX-Session will > try to use it for everything and fail. Use '0launch --feed ROX-Filer/ROX-Filer.xml' on your local copy and it will use that instead. (if you're just logging in and can't get to a prompt, click on 'Add Local Feed...' in the 'Interface Properties' box and select the XML file using the GTK file chooser interface instead) -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2006-01-26 20:21:57
|
In <pan...@ec...>, Thomas Leonard wrote: > On Thu, 26 Jan 2006 19:44:28 +0000, Tony Houghton wrote: > > > In <pan...@ec...>, Thomas Leonard wrote: > > > >> On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: > >> > >> > How does 0install injector handle other languages than Python? > >> > >> ROX-Filer isn't written in Python, and that works fine. > > > > As long as you use 32-bit x86. > > Or PPC64. What are you using? x86_64. > > I know some packages, including ROX-Filer, have source interfaces, but > > some don't, and if you have 0install present at all, ROX-Session will > > try to use it for everything and fail. Hm, looks like I was wrong about ROX-Filer's interface providing source. I know I did find one, but I can't remember what. > Use '0launch --feed ROX-Filer/ROX-Filer.xml' on your local copy and it > will use that instead. Once you've written ROX-Filer.xml. Then you have to do the same for just about every other non-Python package. Just about every ROX app tarball I've ever installed "manually" has managed to compile itself just by trying to run it. Easy. But if you're not on IA32 0install currently does nothing but make things several times more complicated than manually unpacking tarballs. The fix is easy: make it mandatory to provide a platform-neutral implementation (ie source in the case of compiled languages) with the master interface. Still more could be done as a subsequent step, like more automation of creating a tarball and feed interface to encourage more people with "exotic" platforms to submit arch-specific feeds. -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@ec...> - 2006-01-26 21:36:05
|
On Thu, 26 Jan 2006 20:21:48 +0000, Tony Houghton wrote: > In <pan...@ec...>, Thomas Leonard wrote: > >> On Thu, 26 Jan 2006 19:44:28 +0000, Tony Houghton wrote: >> >> > In <pan...@ec...>, Thomas Leonard >> > wrote: >> > >> >> On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: >> >> >> >> > How does 0install injector handle other languages than Python? >> >> >> >> ROX-Filer isn't written in Python, and that works fine. >> > >> > As long as you use 32-bit x86. >> >> Or PPC64. What are you using? > > x86_64. OK. I thought someone offered to make a binary for that, but there doesn't seem to be one at the moment. If you send me one (or create a feed as Ken did) then we can make it work for x86_64 users. Currently, it will probably download an x86 binary on x86_64, as that works on some systems, I think. > Hm, looks like I was wrong about ROX-Filer's interface providing source. I > know I did find one, but I can't remember what. It's not implemented yet, but please add comments here: http://rox.sourceforge.net/desktop/node/218 >> Use '0launch --feed ROX-Filer/ROX-Filer.xml' on your local copy and it >> will use that instead. > > Once you've written ROX-Filer.xml. It comes with one already. > But if you're not on IA32 0install currently does nothing but make > things several times more complicated than manually unpacking > tarballs. 1. Unpack source tarball. 2. Click to compile. 3. Run '0launch --feed ROX-Filer.xml'. If installing to $HOME, works by default. vs 1. Unpack source tarball. 2. Click to compile. 3. Run './install.sh' and follow prompts. If installing to $HOME: 4. Edit your login scripts to set $PATH to include $HOME/bin. Not ideal (it should download and compile the source for you, as you say) but not actually harder. -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2006-01-26 22:48:38
|
In <pan...@ec...>, Thomas Leonard wrote: > On Thu, 26 Jan 2006 20:21:48 +0000, Tony Houghton wrote: > > > In <pan...@ec...>, Thomas Leonard wrote: > > > >> On Thu, 26 Jan 2006 19:44:28 +0000, Tony Houghton wrote: > >> > >> > In <pan...@ec...>, Thomas Leonard > >> > wrote: > >> > > >> >> On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: > >> >> > >> >> > How does 0install injector handle other languages than Python? > >> >> > >> >> ROX-Filer isn't written in Python, and that works fine. > >> > > >> > As long as you use 32-bit x86. > >> > >> Or PPC64. What are you using? > > > > x86_64. > > OK. I thought someone offered to make a binary for that, but there doesn't > seem to be one at the moment. That might have been me, but I couldn't get one of the other apps to work properly with the injector (I think it may have been OroboROX), couldn't work out why, and generally got fed up with it. > If you send me one (or create a feed as Ken > did) then we can make it work for x86_64 users. Would just the executable file be enough for you to do the rest? > > Hm, looks like I was wrong about ROX-Filer's interface providing source. I > > know I did find one, but I can't remember what. > > It's not implemented yet, but please add comments here: > http://rox.sourceforge.net/desktop/node/218 I can't really add much to that except to say I slightly prefer the first model whereby all packages can fall back on the source. > >> Use '0launch --feed ROX-Filer/ROX-Filer.xml' on your local copy and it > >> will use that instead. > > > > Once you've written ROX-Filer.xml. > > It comes with one already. OK, it's in ROX-Filer/../ROX-Filer.xml in the tarball, so I missed it just now. I don't think OroboROX source comes with an interface file though. > > But if you're not on IA32 0install currently does nothing but make > > things several times more complicated than manually unpacking > > tarballs. > > 1. Unpack source tarball. > 2. Click to compile. > 3. Run '0launch --feed ROX-Filer.xml'. If installing to $HOME, works by > default. > > vs > > 1. Unpack source tarball. > 2. Click to compile. > 3. Run './install.sh' and follow prompts. If installing to $HOME: > 4. Edit your login scripts to set $PATH to include $HOME/bin. > > Not ideal (it should download and compile the source for you, as you > say) but not actually harder. That's just ROX-Filer though. Steps 3 and 4 aren't necessary for anything else. I tend to do 4 anyway, and ROX-Session does it for you too. BTW, last time I looked it still didn't check whether ~/bin was already present before adding it again. Even if you are using 0install it's still useful to have rox in your path. Does installing it via 0launch automatically 0alias it for you? -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@ec...> - 2006-01-27 19:49:59
|
On Thu, 26 Jan 2006 22:48:34 +0000, Tony Houghton wrote: > In <pan...@ec...>, Thomas Leonard wrote: >> On Thu, 26 Jan 2006 20:21:48 +0000, Tony Houghton wrote: [...] >> > x86_64. >> >> If you send me one (or create a feed as Ken did) then we can make it >> work for x86_64 users. > > Would just the executable file be enough for you to do the rest? Depends if it needs to be kept up-to-date (if you host the feed you don't need to send me new versions). Otherwise, a GPG-signed binary is fine, like the x86 one here: http://sourceforge.net/project/showfiles.php?group_id=7023&package_id=7131&release_id=381737 >> > Hm, looks like I was wrong about ROX-Filer's interface providing >> > source. I know I did find one, but I can't remember what. >> >> It's not implemented yet, but please add comments here: >> http://rox.sourceforge.net/desktop/node/218 > > I can't really add much to that except to say I slightly prefer the first > model whereby all packages can fall back on the source. We can't guarantee that people will provide source, but if we can make the compile-a-binary process fully automatic then hopefully people will just naturally use that method to produce the binaries. I'm hoping to improve the tools a bit this weekend, if I get some time. >> > Once you've written ROX-Filer.xml. >> >> It comes with one already. > > OK, it's in ROX-Filer/../ROX-Filer.xml in the tarball, so I missed it just > now. I don't think OroboROX source comes with an interface file though. The source version on rox.sf.net does, but I don't have any control over the upstream version. However, the patch is here: http://sourceforge.net/project/showfiles.php?group_id=7023&package_id=161520&release_id=385614 [...] >> Edit your login scripts to set $PATH to include $HOME/bin. >> >> Not ideal (it should download and compile the source for you, as you >> say) but not actually harder. > > That's just ROX-Filer though. Steps 3 and 4 aren't necessary for anything > else. I tend to do 4 anyway, and ROX-Session does it for you too. BTW, > last time I looked it still didn't check whether ~/bin was already present > before adding it again. I guess the Python version will make that easier. Stephen's new Environment.py would probably be a good place for it. > Even if you are using 0install it's still useful to have rox in your path. > Does installing it via 0launch automatically 0alias it for you? No (but 0aliasing it will 0launch it). ROX-Session puts an extra bin directory in your PATH which contains a 'rox' launcher script. -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Jonatan L. <li...@ky...> - 2006-01-26 21:09:27
|
On Thu, 26 Jan 2006 19:58:44 +0000 Thomas Leonard <ta...@ec...> wrote: > On Thu, 26 Jan 2006 19:44:28 +0000, Tony Houghton wrote: > > > In <pan...@ec...>, Thomas Leonard > > wrote: > > > >> On Wed, 25 Jan 2006 22:48:10 -0200, Jonatan Liljedahl wrote: > >> > >> > How does 0install injector handle other languages than Python? > >> > >> ROX-Filer isn't written in Python, and that works fine. > > > > As long as you use 32-bit x86. > > Or PPC64. What are you using? > > > I know some packages, including ROX-Filer, have source interfaces, > > but some don't, and if you have 0install present at all, > > ROX-Session will try to use it for everything and fail. > > Use '0launch --feed ROX-Filer/ROX-Filer.xml' on your local copy and it > will use that instead. Why not do this automagically? Or at least provide a menu entry on AppDirs that does have a local interface file to add it. (imho, it should not be acceptable with 0install apps without such a ready-made local feed file) /Jonatan -=( http://kymatica.com )=- |
From: Lennon C. <mag...@gm...> - 2006-01-25 23:14:43
|
Jonatan Liljedahl wrote: > I just came up with an idea about how one can solve the issue with > relocatable LibDirs and how to find them. What's wrong with an envvar, LIBDIRPATH, that gives locations where the system can expect to find libdirs? This has several advantages to your suggestion, not the least of which is that it /already exists/ in findrox.py . Also, there is no need for a library to register itself=20 on the system (which seems to me to be a little too reminiscent of the non-relocatable package managers). The only disadvantage I can see is that existing systems don't use it already (except findrox.py), and so there needs to be a generalised findrox.py to find any library - but this exists in your suugestion, too. To find another *app*, it would be nice if it were easy to treat it as a single executable and have it in $PATH... but, AFAIK, the current ways to do this only work from the shell (unless you have a directory full of symlinks to AppRun in the various dirs, but then you would need to update it everytime you add, remove, or rename an app; and it bears resemblance to a package management database that needs to be kept consistant..). -- Lennon Victor Cook "He who receives an idea from me receives without lessening, as he who lights his candle at mine receives light without darkening" - Thomas Jefferson |
From: Jonatan L. <li...@ky...> - 2006-01-25 23:48:12
|
On Thu, 26 Jan 2006 10:14:29 +1100 Lennon Cook <mag...@gm...> wrote: > Jonatan Liljedahl wrote: > > I just came up with an idea about how one can solve the issue with > > relocatable LibDirs and how to find them. > What's wrong with an envvar, LIBDIRPATH, that gives locations where > the system can expect to find libdirs? This has several advantages to > your suggestion, not the least of which is that it /already exists/ in > findrox.py . Also, there is no need for a library to register itself > on the system (which seems to me to be a little too reminiscent of the > non-relocatable package managers). The only disadvantage I can see is > that existing systems don't use it already (except findrox.py), and > so there needs to be a generalised findrox.py to find any library - > but this exists in your suugestion, too. To find another *app*, it > would be nice if it were easy to treat it as a single executable and > have it in $PATH... but, AFAIK, the current ways to do this only work > from the shell (unless you have a directory full of symlinks to AppRun > in the various dirs, but then you would need to update it everytime > you add, remove, or rename an app; and it bears resemblance to a > package management database that needs to be kept consistant..). I think my suggestion is *more* relocatable than using LIBDIRPATH, since you would need to put the app/lib in one of the paths listed in this variable. Scanning for apps/libs in LIBDIRPATH takes time, especially if you have lots of apps/libs... Apps already have stuff in XDG_CONFIG_HOME so it would not actually add anything, except one small one-liner file. (or maybe use a symlink instead). Compare the time to scan a directory structure against just following a symlink. And note that this would work the same for apps and libs. You can't add all rox apps to your PATH unless you patch /bin/sh to search for AppRun scripts... Having a dir full of symlinks to AppRun scripts doesn't work in many cases since dirname reports the location of the symlink, not the target of the symlink. /Jonatan -=( http://kymatica.com )=- |
From: Jonatan L. <li...@ky...> - 2006-01-26 18:33:07
|
On Thu, 26 Jan 2006 11:21:24 +1100 Lennon Cook <mag...@gm...> wrote: > Jonatan Liljedahl wrote: > > I think my suggestion is *more* relocatable than using LIBDIRPATH, > > since you would need to put the app/lib in one of the paths listed > > in this variable. > Or update LIBDIRPATH. But, yes, I see your point. > > >Scanning for apps/libs in LIBDIRPATH takes time, > > especially if you have lots of apps/libs... Apps already have stuff > > in XDG_CONFIG_HOME so it would not actually add anything, except > > one small one-liner file. (or maybe use a symlink instead). > A symlink does sound good, now you mention it. But it would still be > nice to not have to register a library by running it once - think > about, for example, a package installed somewhere in / by the > sysadmin. It would be inideal if it had to be run once by each user > before they could run an app that uses it. An obvious workaround is to > have a system-wide place where these symlinks could be looked for, > with preference placed on $XDG_CONFIG_HOME if the link exists there. Yes, exactly. system-wide libs would be registered system-wide... not much different from the fact that a system-wide appdir could need to be compiled first (by root). > But this could easily end up taking as much time as scanning the > $LIBDIRPATH directories (although, I admit, it does have the advantage > of having the libraries be relocatable without adjusting the envvars). In what way would it take time? /Jonatan -=( http://kymatica.com )=- |
From: Lennon C. <mag...@gm...> - 2006-01-26 20:32:50
|
Jonatan Liljedahl wrote: > > But this could easily end up taking as much time as scanning the > > $LIBDIRPATH directories (although, I admit, it does have the advantage > > of having the libraries be relocatable without adjusting the envvars). > > In what way would it take time? In the same way that scanning $LIBDIRPATH would take time - you have several directories to scan for a particular filename. The only difference I see is exactly *what* you're looking for (a domain/libname/path symlink/conf file or libName dir). The processes would be, near as I can tell, exactly the same. -- Lennon Victor Cook "He who receives an idea from me receives without lessening, as he who lights his candle at mine receives light without darkening" - Thomas Jefferson |
From: Jonatan L. <li...@ky...> - 2006-01-26 22:24:19
|
On Fri, 27 Jan 2006 07:32:45 +1100 Lennon Cook <mag...@gm...> wrote: > Jonatan Liljedahl wrote: > > > But this could easily end up taking as much time as scanning the > > > $LIBDIRPATH directories (although, I admit, it does have the > > > advantage of having the libraries be relocatable without > > > adjusting the envvars). > > > > In what way would it take time? > In the same way that scanning $LIBDIRPATH would take time - you have > several directories to scan for a particular filename. The only > difference I see is exactly *what* you're looking for (a > domain/libname/path symlink/conf file or libName dir). The processes > would be, near as I can tell, exactly the same. Yes, you're absolutely right. It would actually not be any scanning at all, just trying to get a file named $LIBDIRPATH/LibName... I was thinking about scanning becouse I have all my appdirs in categories and that would require a recursive search for a file, not just a filename lookup. But in that case you could easily add these subdirs to LIBDIRPATH, it would probably not be too big. /Jonatan -=( http://kymatica.com )=- |