Generic module test on extensions that depend on other scripted modules/extensions are failing

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Generic module test on extensions that depend on other scripted modules/extensions are failing

criskross
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

Steve Pieper-2
Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

criskross
In reply to this post by criskross
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

Steve Pieper-2
In reply to this post by criskross
Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

criskross
In reply to this post by criskross
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian
On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ





_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

Steve Pieper-2
In reply to this post by criskross
Hi Christian - 

I don't think there's a vm or anything.  I think the only way to replicate the factories in a local build is to track through the logic of the cmake scripts that implement the extension build process.

We should see if @jcfr has any pointers for this, but I believe all the needed scripts are available in the repository and other info is on the wiki.

Basically each extension gets it's own build directory and when the tests are launched they need to have the same path information that an installation would need to find the packages.  If you print sys.path in an slicer release installation you will see the directories of any installed directories listed.  I think the errors you are seeing are due to the extension test environment not having the corresponding paths to the dependent extensions.

I agree it's not easy to set up the extension build for this troubleshooting.  Since you are just testing why the test scripts don't run I'd think it's easier to add something like print(sys.path) at the top of the script and seeing what you can figure out indirectly.

Sorry, I don't know if there's an easier way to investigate this,
-Steve

On Thu, Mar 2, 2017 at 12:22 PM, Christian Herz <[hidden email]> wrote:
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian

On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ






_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

Isaiah Norton-2
To the extent that this is caused by lacking the paths in AdditionalLauncherSettings (http://www.na-mic.org/Bug/view.php?id=4242) I think it should be fixed by this PR: https://github.com/commontk/AppLauncher/pull/60


On Thu, Mar 2, 2017 at 12:35 PM, Steve Pieper <[hidden email]> wrote:
Hi Christian - 

I don't think there's a vm or anything.  I think the only way to replicate the factories in a local build is to track through the logic of the cmake scripts that implement the extension build process.

We should see if @jcfr has any pointers for this, but I believe all the needed scripts are available in the repository and other info is on the wiki.

Basically each extension gets it's own build directory and when the tests are launched they need to have the same path information that an installation would need to find the packages.  If you print sys.path in an slicer release installation you will see the directories of any installed directories listed.  I think the errors you are seeing are due to the extension test environment not having the corresponding paths to the dependent extensions.

I agree it's not easy to set up the extension build for this troubleshooting.  Since you are just testing why the test scripts don't run I'd think it's easier to add something like print(sys.path) at the top of the script and seeing what you can figure out indirectly.

Sorry, I don't know if there's an easier way to investigate this,
-Steve

On Thu, Mar 2, 2017 at 12:22 PM, Christian Herz <[hidden email]> wrote:
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian

On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ






_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

Steve Pieper-2
In reply to this post by Steve Pieper-2
Makes sense to me!

On Thu, Mar 2, 2017 at 1:14 PM, Isaiah Norton <[hidden email]> wrote:
To the extent that this is caused by lacking the paths in AdditionalLauncherSettings (http://www.na-mic.org/Bug/view.php?id=4242) I think it should be fixed by this PR: https://github.com/commontk/AppLauncher/pull/60


On Thu, Mar 2, 2017 at 12:35 PM, Steve Pieper <[hidden email]> wrote:
Hi Christian - 

I don't think there's a vm or anything.  I think the only way to replicate the factories in a local build is to track through the logic of the cmake scripts that implement the extension build process.

We should see if @jcfr has any pointers for this, but I believe all the needed scripts are available in the repository and other info is on the wiki.

Basically each extension gets it's own build directory and when the tests are launched they need to have the same path information that an installation would need to find the packages.  If you print sys.path in an slicer release installation you will see the directories of any installed directories listed.  I think the errors you are seeing are due to the extension test environment not having the corresponding paths to the dependent extensions.

I agree it's not easy to set up the extension build for this troubleshooting.  Since you are just testing why the test scripts don't run I'd think it's easier to add something like print(sys.path) at the top of the script and seeing what you can figure out indirectly.

Sorry, I don't know if there's an easier way to investigate this,
-Steve

On Thu, Mar 2, 2017 at 12:22 PM, Christian Herz <[hidden email]> wrote:
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian

On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ






_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

Isaiah Norton-2
In reply to this post by Steve Pieper-2
Actually, I forgot, that is a precursor to fixing it. Here's the local changes I made to take the settings in to account:



On Thu, Mar 2, 2017 at 1:16 PM, Steve Pieper <[hidden email]> wrote:
Makes sense to me!

On Thu, Mar 2, 2017 at 1:14 PM, Isaiah Norton <[hidden email]> wrote:
To the extent that this is caused by lacking the paths in AdditionalLauncherSettings (http://www.na-mic.org/Bug/view.php?id=4242) I think it should be fixed by this PR: https://github.com/commontk/AppLauncher/pull/60


On Thu, Mar 2, 2017 at 12:35 PM, Steve Pieper <[hidden email]> wrote:
Hi Christian - 

I don't think there's a vm or anything.  I think the only way to replicate the factories in a local build is to track through the logic of the cmake scripts that implement the extension build process.

We should see if @jcfr has any pointers for this, but I believe all the needed scripts are available in the repository and other info is on the wiki.

Basically each extension gets it's own build directory and when the tests are launched they need to have the same path information that an installation would need to find the packages.  If you print sys.path in an slicer release installation you will see the directories of any installed directories listed.  I think the errors you are seeing are due to the extension test environment not having the corresponding paths to the dependent extensions.

I agree it's not easy to set up the extension build for this troubleshooting.  Since you are just testing why the test scripts don't run I'd think it's easier to add something like print(sys.path) at the top of the script and seeing what you can figure out indirectly.

Sorry, I don't know if there's an easier way to investigate this,
-Steve

On Thu, Mar 2, 2017 at 12:22 PM, Christian Herz <[hidden email]> wrote:
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian

On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ






_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

criskross
In reply to this post by Steve Pieper-2
The following code works for me locally. But this would only be a temporary solution since the dashboard needs to figure out the build paths for the extensions SliceTracker depends on.

set(SlicerProstate_BUILD_DIR /Users/christian/sources/py/SlicerProstate/Build/)

slicer_add_python_unittest(
  SCRIPT SliceTrackerTests.py
  SLICER_ARGS
    --additional-module-paths ${SlicerProstate_BUILD_DIR}${Slicer_QTSCRIPTEDMODULES_LIB_DIR}
  )

Christian


On Mar 2, 2017, at 1:31 PM, Isaiah Norton <[hidden email]> wrote:

Actually, I forgot, that is a precursor to fixing it. Here's the local changes I made to take the settings in to account:



On Thu, Mar 2, 2017 at 1:16 PM, Steve Pieper <[hidden email]> wrote:
Makes sense to me!

On Thu, Mar 2, 2017 at 1:14 PM, Isaiah Norton <[hidden email]> wrote:
To the extent that this is caused by lacking the paths in AdditionalLauncherSettings (http://www.na-mic.org/Bug/view.php?id=4242) I think it should be fixed by this PR: https://github.com/commontk/AppLauncher/pull/60


On Thu, Mar 2, 2017 at 12:35 PM, Steve Pieper <[hidden email]> wrote:
Hi Christian - 

I don't think there's a vm or anything.  I think the only way to replicate the factories in a local build is to track through the logic of the cmake scripts that implement the extension build process.

We should see if @jcfr has any pointers for this, but I believe all the needed scripts are available in the repository and other info is on the wiki.

Basically each extension gets it's own build directory and when the tests are launched they need to have the same path information that an installation would need to find the packages.  If you print sys.path in an slicer release installation you will see the directories of any installed directories listed.  I think the errors you are seeing are due to the extension test environment not having the corresponding paths to the dependent extensions.

I agree it's not easy to set up the extension build for this troubleshooting.  Since you are just testing why the test scripts don't run I'd think it's easier to add something like print(sys.path) at the top of the script and seeing what you can figure out indirectly.

Sorry, I don't know if there's an easier way to investigate this,
-Steve

On Thu, Mar 2, 2017 at 12:22 PM, Christian Herz <[hidden email]> wrote:
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian

On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ






_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ





_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Generic module test on extensions that depend on other scripted modules/extensions are failing

criskross
What I am doing locally right now:

I have a nightly Slicer installed which has all required extensions installed:

1. I set an environment variable SLICER_EXTENSIONS_DIR to my Slicer extension directory
2. I added the following code to my CMakeLists.txt:

macro(getExtensions subdirs directory)
  file(GLOB children RELATIVE ${directory} ${directory}/*)
  set(dirList "")
  foreach(child ${children})
    if(IS_DIRECTORY ${directory}/${child})
      list(APPEND dirList ${child})
    endif()
  endforeach()
  set(${subdirs} ${dirList})
endmacro()

getExtensions(possibleExtensions $ENV{SLICER_EXTENSIONS_DIR})

set(ADDITIONAL_MODULE_PATHS)

FOREACH(subdir ${possibleExtensions})
  #message("${EXTENSION_DEPENDS}")
  string(FIND "${EXTENSION_DEPENDS}" "${subdir}" pos)
  if(${pos} GREATER -1)
    message("$ENV{SLICER_EXTENSIONS_DIR}/${subdir}/${Slicer_QTSCRIPTEDMODULES_LIB_DIR}")
    list(APPEND ADDITIONAL_MODULE_PATHS "$ENV{SLICER_EXTENSIONS_DIR}/${subdir}/${Slicer_QTSCRIPTEDMODULES_LIB_DIR}")
  endif()
  #ADD_SUBDIRECTORY(${subdir})
ENDFOREACH()


slicer_add_python_unittest(
  SCRIPT SliceTrackerTests.py
  SLICER_ARGS
    --additional-module-paths ${ADDITIONAL_MODULE_PATHS}
  )


This gives me the following output and works fine.

1: Test command: /Users/christian/sources/cpp/Slicer/Build/Slicer-build/Slicer "--no-splash" "--testing" "--launcher-additional-settings" "/Users/christian/sources/py/SliceTracker_1/Build/AdditionalLauncherSettings.ini" "--python-code" "import slicer.testing; slicer.testing.runUnitTest(['/Users/christian/sources/py/SliceTracker_1/Build/Testing', '/Users/christian/sources/py/SliceTracker_1/Testing'], 'SliceTrackerTests')" "--additional-module-paths" "/Applications/Slicer.app/Contents/Extensions-25707/SlicerProstate/lib/Slicer-4.7/qt-scripted-modules" "/Applications/Slicer.app/Contents/Extensions-25707/VolumeClip/lib/Slicer-4.7/qt-scripted-modules" "/Applications/Slicer.app/Contents/Extensions-25707/mpReview/lib/Slicer-4.7/qt-scripted-modules”


I could imagine that we could do the same on the build factory machine?

Christian


On Mar 2, 2017, at 2:01 PM, Christian Herz <[hidden email]> wrote:

The following code works for me locally. But this would only be a temporary solution since the dashboard needs to figure out the build paths for the extensions SliceTracker depends on.

set(SlicerProstate_BUILD_DIR /Users/christian/sources/py/SlicerProstate/Build/)

slicer_add_python_unittest(
  SCRIPT SliceTrackerTests.py
  SLICER_ARGS
    --additional-module-paths ${SlicerProstate_BUILD_DIR}${Slicer_QTSCRIPTEDMODULES_LIB_DIR}
  )

Christian


On Mar 2, 2017, at 1:31 PM, Isaiah Norton <[hidden email]> wrote:

Actually, I forgot, that is a precursor to fixing it. Here's the local changes I made to take the settings in to account:



On Thu, Mar 2, 2017 at 1:16 PM, Steve Pieper <[hidden email]> wrote:
Makes sense to me!

On Thu, Mar 2, 2017 at 1:14 PM, Isaiah Norton <[hidden email]> wrote:
To the extent that this is caused by lacking the paths in AdditionalLauncherSettings (http://www.na-mic.org/Bug/view.php?id=4242) I think it should be fixed by this PR: https://github.com/commontk/AppLauncher/pull/60


On Thu, Mar 2, 2017 at 12:35 PM, Steve Pieper <[hidden email]> wrote:
Hi Christian - 

I don't think there's a vm or anything.  I think the only way to replicate the factories in a local build is to track through the logic of the cmake scripts that implement the extension build process.

We should see if @jcfr has any pointers for this, but I believe all the needed scripts are available in the repository and other info is on the wiki.

Basically each extension gets it's own build directory and when the tests are launched they need to have the same path information that an installation would need to find the packages.  If you print sys.path in an slicer release installation you will see the directories of any installed directories listed.  I think the errors you are seeing are due to the extension test environment not having the corresponding paths to the dependent extensions.

I agree it's not easy to set up the extension build for this troubleshooting.  Since you are just testing why the test scripts don't run I'd think it's easier to add something like print(sys.path) at the top of the script and seeing what you can figure out indirectly.

Sorry, I don't know if there's an easier way to investigate this,
-Steve

On Thu, Mar 2, 2017 at 12:22 PM, Christian Herz <[hidden email]> wrote:
Hi Steve,

How would I mimic that? Is there any VM that I can download which simulates the build factory i.e. for Mac OS?

I was thinking about installing the extension with CMake into the Slicer-build directory, but I am not sure if that would be a good idea.

Christian

On Mar 2, 2017, at 11:21 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

Yes, I think that EXTENSION_DEPENDS line is right because it works in the nightly and release packages.

I haven't looked at the details, but I suspect the scenario for ctest on the factories is that the extensions are in their build directories (not installed) and so the launcher paths include the right entries for all the dependencies to be resolved.

What I was thinking is that if you create a build environment that mimics the layout of the factory machines with build directories for mpReview and SliceTracker you could run ctest from within that those and see if you get the same results as reported on the dashboard.  From there it would be possible to print the sys.path and see what needs to be done to find the dependent extensions.

Or, you could add printing of diagnostic info to the tests themselves and watch the dashboard to see what is missing.

HTH,
Steve



On Thu, Mar 2, 2017 at 9:54 AM, Christian Herz <[hidden email]> wrote:
Hi Steve,

thanks for the quick reply.

I read the FAQ and as far as I can tell I did everything written there.

set(EXTENSION_DEPENDS Extension1)

How does the ctest work?
Isn’t there anything missing when starting the Slicer instance for testing? 
Somehow the ctest needs at least to know which others extensions are required, right?

Thanks,
Christian

On Mar 2, 2017, at 9:05 AM, Steve Pieper <[hidden email]> wrote:

Hi Christian - 

I haven't tried that scenario (testing extensions depending on other extensions) but it should be possible to recreate that on your own machine.  Does the FAQ not cover this case?


-Steve

On Wed, Mar 1, 2017 at 11:47 PM, Christian Herz <[hidden email]> wrote:
Hi developers,

I noticed that all generic tests on SliceTracker[1] and mpReview[2] fail on the dashboard[3][4] even when I build them manually and run ctest locally I get ImportError. 

Those extensions have dependencies to other scripted modules like VolumeClip[5] and SlicerProstate[6].

1. Does anyone know why? 
2. What’s the order of dependencies to be loaded when the ctest instance of Slicer starts?
3. Are there any restrictions to those generic tests?

Hope anyone can help.

Thanks Christian




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ






_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ




_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ