2017-03-02 2:44 GMT+01:00 Bert Freudenberg <bert at freudenbergs.de>:
> On Wed, Mar 1, 2017 at 3:42 PM, Jakob Reschke <jakob.reschke at student.hpi.de>
> wrote:
>>
>>
>> My Environments use case, for which I have gone through all of this,
>> is that I need to use and work on a Pharo package that uses the
>> FileSystem library. The FileSystem classes have different names in
>> Pharo, compared to the FS package available on SqueakSource.
>
>
>
> Can you walk us through this use case? What tools do you use in which order?

Well, if I were to start from scratch with my changes already in the
image, I would do the following:

1. prepare the environment in a workspace, because there are no tools for it:

   env := Environment named: #NewProjectWithPharoBindings.
   env import: Smalltalk globals.
   env from: Smalltalk globals import: { #FSFilesystem -> #FileSystem.
#FSPath -> #Path. "..." }
   env importSelf; exportSelf.

2. open a Workspace that "lives" in the new environment:

  env beCurrentDuring: [Workspace open]

  ...and change its title to remember its purpose.

3. in the Monticello Browser, add a working copy for the package I
want to work on (+ Package)
4. right-click on it > change environment... choose my new environment
named NewProjectWithPharoBindings.

5. add the appropriate repository, open it, load the package -or- use
Metacello to do it (you have to know the relevant package names and
prepare them with steps 3 and 4) -but- I have not checked if Metacello
goes through the MCWorkingCopy, so this might not work yet. In that
case, wrap "env beCurrentDuring: [...]" around the Metacello load.
This might be the easier way after all...

6. in the workspace created in step 2, send #browse to a class loaded
in step 5, to open a browser in the new environment

7. if appropriate and desired, import some or all of the new classes
back into Smalltalk globals. This also simplifies opening browsers,
because you can do it via the search box.

   Smalltalk globals from: env import: { ... }.

Then I do whatever I intend to do with that package. Probably port the
code when selectors have changed as well, not only the class names.
This is (ideally) no different from developing without environments.

I did not commit the TestRunner yet... like for Workspace, I added an
environment instvar there. Will do that later today.

>
>> A remaining issue is that FSPath was renamed Path, which conflicts with
>> ST80's Path class.
>
>
> Our environments support renaming, doesn't that help?
>

Yes, it does. What I meant is that because of this name conflict, I
require another environment at all. Unless I consider it desirable to
rename one of the Path classes and possibly change all the references
from Path to FSPath in the loaded package. Or rename Path to St80Path
and hope that nobody will ever add another method uses it under the
name "Path". It is not possible to load a version of FileSystem where
FSPath is called Path into the same environment as ST80 without
overwriting ST80's Path.

There is another pitfall with renamed imports and Monticello: The
class definition includes the superclass name -- its proper name, not
the renamed binding (for all we know, the class could have multiple
bindings in this environment...) All subclasses of FileSystem always
show up in the diff because as far as Monticello is concerned, the
superclass was changed from FileSystem to FSFilesystem, although these
are really the same thing. One could add special checks for that case
and manipulate the MCClassDefinition to not reflect the "superclass
name change". Otherwise the problem would resurface when the class
definition really changes and must be committed. Too bad everything is
so text based for us humans because we cannot read pointers or
remember UUIDs for classes. ;-)