On 9 November 2017 at 10:18, Guillermo Polito <guillermopol...@gmail.com> wrote: > > An analysis of the situation so people out of context can understand better > the forces in play here :) > > - Working directory and files constant property: files defined using a > *relative path* are created relative to the working directory. > In other words: > File named: 'something/other/myfile.txt' > will be created in FileSystem workingDirectory. > This was always like this when we used the file primitives. > The diverging behaviour was introduced actually by FileSystem: FileSystem > used to create by default all files relative to the image directory. And at > some point all tools adapted to that and the correct behaviour was hidden. > > - Change in working directory: Before, pharo always satisfied the following > property: > FileSystem workingDirectory = FileSystem imageDirectory
I realise I'm being pedantic, so apologies in advance and I certainly don't mean to offend anyone. Just for completeness: This constraint was actually introduced in Pharo 6 around March 2017. I think it was issue #19717 (https://pharo.fogbugz.com/f/cases/19717/FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder). Before that the workingDirectory was held in an instance variable and could be changed (although it looks like no one actually did that). #20164 (https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDirectory) put the workingDirectory back in to a class variable since the performance gain is significant (one application saved 12 seconds from the change). > This is no longer true for every case. > Now, the workingDirectory is aligned with the process' working directory > (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash). Cheers, Alistair > I explained a couple of weeks ago in an email, this may break some eggs, > specially for those tools that wrongly assume FileSystem workingDirectory = > FileSystem imageDirectory. > Tools requiring imageDirectory should use imageDirectory explicit. At > least that will keep backwards compatibility. > For other cases, we should probably study them case by case and provide a > satisfying solution. > > This change does however not affect everybody, and most of the times it is > backwards compatible: > > ** This does not affect in general people launching usually pharo from the > command line and using zeroconf: > $ wget get.pharo.org/... > $ ./pharo Pharo.image > ## Here, FileSystem workingDirectory = FileSystem imageDirectory > because I launched my image from the directory where my image is! > > ** This does affect people that are: > - launching Pharo doing double click. > In this case, we saw with Denis and Pavel a week ago that osx > assigns as working directory the root directory "/" > Users of files should be aware of this and applications should not > abuse the workingDirectory. If they want to enforce the imageDirectory, they > should do so explicitly. > > - launching Pharo from the pharo launcher (taken from this thread) > Apparently the pharo launcher is launching the image from a > directory internal to the launcher. This means that the working directory > will be assigned to that directory. I'd expect that the directory structure > is private to the launcher... > I find even strange that the launcher puts pharo-local where the > image is... > > > Given this, possible solutions are: > - On fileout, chose a correct directory when launched from double click > - Make the pharo launcher set a well-known working directory when launching > an image > - one possibility is to set $HOME > - another possibility is to set the image directory (this will keep > backwards compatibility) > > @Stef: about the #fullname. It is not there because it is not implemented :). > We did not have the possibility of calculating a correct full path until a > couple of weeks ago (and before, even if we did so, it couldn't be done > without introducing a dependency to a non-kernel package). > > On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey > <christophe.dema...@inria.fr> wrote: >> >> Hi Stefan, >> >> > Le 8 nov. 2017 à 15:56, stephan <step...@stack.nl> a écrit : >> > >> > I run into all kinds of issues with the directory structure used by the >> > new PharoLauncher. pharo-local seems to be shared now for multiple images. >> >> I never saw this issue. >> PharoLauncher does not have influence on the pharo-local directory of >> launched images. pharo-local directory is located in the same directory as >> the image run. >> >> in a Pharo 6.1 image: >> localDirectory >> ^ self class userLocalDirectory >> ifNil: [ (self imageDirectory / self class >> defaultLocalDirectoryName) ensureCreateDirectory ] >> >> userLocalDirectory >> ^ UserLocalDirectory ifNil: [ >> FileLocator workingDirectory / self >> defaultLocalDirectoryName ] >> >> >> Maybe you run Pharo 7 images and this change « Build #203: >> 05723-Default-Working-Directory » has a side effect? >> >> > That makes using configurations practically impossible as they are not >> > expecting to have to deal with pre-downloaded older and newer monticello >> > files. The missing sources files is less of a problem. >> > >> > Stephan >> > >> > >> >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13
