Circular Dependency

In the two baselines below, I assumed that since one used "requires" and the other "includes", there would be no circular dependency. Unfortunately, when I try to load or record, MetaC churns endlessly between the two.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/944da425-b790-451d-bd99-3c91584dc383n%40googlegroups.com.

Sean,

I don't have enough information to understand what is going on .... you've given me two baseline specs, but I don't know which projects they belong to ... as a result I don't know which "two" are endlessly churning .... A snippet of the Transcript might help as well as there would possibly be clues as to which packages are involved in the loop ...

Dale

In the two baselines below, I assumed that since one used "requires" and the other "includes", there would be no circular dependency. Unfortunately, when I try to load or record, MetaC churns endlessly between the two.

Here's one:

baseline: spec

<baseline>

spec for: #'common' do: [

spec

baseline: 'PharoEnhancements' with: [

spec repository: 'github://seandenigris/Pharo-Enhancements' ];

baseline: 'SimplePersistence' with: [

spec repository: 'github://seandenigris/Simple-Persistence' ];

baseline: 'Superuser' with: [

spec repository: 'github://seandenigris/Superuser' ];

baseline: 'Tesseract' with: [

spec

repository: 'github://seandenigris/Tesseract-St' ].

spec package: #ResourcesLive with: [

spec requires: #('PharoEnhancements' 'SimplePersistence' 'Superuser' 'Tesseract'). ]. ].

And here is the other:

baseline: spec

<baseline>

spec for: #common do: [

spec

baseline: 'OSSubprocess' with: [

spec repository: 'github://pharo-contributions/OSSubprocess' ];

baseline: 'ResourcesLive' with: [

spec repository: 'github://seandenigris/Resources-Live' ];

baseline: 'Superuser' with: [

spec repository: 'github://seandenigris/Superuser' ];

baseline: 'Tempfile' with: [

spec repository: 'github://seandenigris/TempfileSt' ].

spec

package: 'Tesseract'

with: [ spec 

requires: #('OSSubprocess' 'Superuser' 'Tempfile');

includes: #('ResourcesLive') ] ].

spec for: #GToolkit do: [

spec package: 'Tesseract-Bloc' with: [ spec requires: #('Tesseract') ] ]

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/944da425-b790-451d-bd99-3c91584dc383n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/96e0cee8-b22b-15a4-2841-975237cfb2c3%40gemtalksystems.com.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/019eaa3e-2dd4-4fd9-9574-a65a5907ca56n%40googlegroups.com.

On Wednesday, September 30, 2020 at 12:40:07 PM UTC-4 Dale wrote:Sean,

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/41a37c40-6aca-45a0-aaa7-280637d8c195n%40googlegroups.com.

On Wednesday, September 30, 2020 at 1:35:24 PM UTC-4 Sean DeNigris wrote:

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/cb84b866-e759-4289-8be8-1c98ad6107b2n%40googlegroups.com.

Sean,

Sorry I am a bit buried with work on a couple of releases (we shipped one release yesterday and are scheduled to make another release in the next couple of weeks:) so I haven't had a lot of time to analyze the problem ...

With that said, I will try to make some time in the next couple of days, to see what I can figure out ...

I've taken a quick look at the file and nothing jumped out at me - I wasn't able to get a handle on the loop, but it does seem to involve a whole bunch of projects, so it is a subtle loop ... My screen is tall enough for me to see the loop:)

Just the other day, I did the work to break an infinite Metacello load loop between Seaside and Parasol, so I did learn a couple of things that may or may not help.

Metacello does not detect project loops. Metacello will detect package dependency loops, but a project reference loop not involving packages will go undetected ... Of course by detecting a loop, I mean that an error was thrown.

I see that you are using a number public projects intermixed with your own projects, so I'm going to guess that the loop is introduced by one of your projects. The public projects don't usually have undetected load loops ...

The Seaside/Parasol loop was interesting, because the initial bare install succeeded and the loop didn't show up until I tried to reload a project. Are you seeing something similar.

Since you are familiar with all of the projects, you should think about where you have created a dependency on a project on only a subset of a larger project that is used in its entirety elsewhere ... if you know of this you need to arrange to remove the loop by deciding which project is the master and arrange for it to be loaded first.

If you learn things before I have a chance to dig in deeper, please let me know

Dale

On Wednesday, September 30, 2020 at 1:35:24 PM UTC-4 Sean DeNigris wrote:

Sorry :) Here is some of the (seemingly endless) transcript output after the following (GT with Pharo 8 64-bit underneath, MacOS):

Any thoughts on how to get around this? It's causing me grief on my current project, which gets loaded into a fresh image almost daily... 

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/cb84b866-e759-4289-8be8-1c98ad6107b2n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/cc474f0b-0b29-6104-087f-0145041de934%40gemtalksystems.com.

> (we shipped one release yesterday and are scheduled to make another release in the next couple of weeks:)

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/194570f6-c638-4a19-82e2-1950ea890685n%40googlegroups.com.

The hazards of writing email on the critical path:)

My screen is tall enough for me to see the loop:)

My screen is NOT tall enough for me to see the loop:)

Another good problem ;-) 

I see that you are using a number public projects intermixed with your own projects, so I'm going to guess that the loop is introduced by one of your projects. The public projects don't usually have undetected load loops ...

I'm guessing you mean "personal" rather than private, because I think all the dependencies are publicly accessible.

I should have said that public projects don't usually have undetected load loops when the standard entry points are used, otherwise they would have been reported and fixed.

Magritte, OSSubProcess, Grease, NeoCsv are used in a number of places without hitting loops, but the fact that these projects appear to be part of the loop leads me to believe the the loop is introduce in one of "your projects" ---

I see that you are using very few public projects without a personal fork and I would be suspicious of any changes that you have made to the baselines of these projects  ...

Oh look almost all of the projects involved in the loop seem to involve *-CompatibleUserName baselines and those are all presumably additions that you have made and the loop is almost certainly in the customization that you've done in those baselines ...

The log doesn't have information about the first entry point into the *-CompatibleUserName baselines in your load, but I would look very closely at that first entry point and find the other projects involved in the loop and find the one that uses the same entry point ...

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/42645994-4237-6ba7-7e76-98602ccf991a%40gemtalksystems.com.