Cannot install labscript- Solving environment: failed

[Trey Porto]

Hi all,  

Some months ago I replaced a bricked MacBookPro, which I used (among other things) for labscript development when I'm away from the lab.

I need to do some device development work, and I am trying to get Labscript working on the new laptop. Failing to get quickly get my old installation to work,  I tried a completely new installation in a new environment, which surprisingly failed (see below)

I attempted the install with various different versions of python,  different syntaxes, including "pyqt<6", not including "pyqt<6" , etc. and every time I get the

labscript-suite is not installable because there are no viable options

error.

We are very keen to do some needed software development ASAP, so any assistance would be highly appreciated.

Cheers,

Trey

example transcript:

_____________________________________________________________________________

(base) treyporto@Treys-MBP ~ % conda create --name labscript python=3.11

(base) treyporto@Treys-MBP ~ % conda activate labscript

(labscript) treyporto@Treys-MBP ~ % conda install labscript-suite::labscript-suite

Channels:  

- defaults

- labscript-suite

Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: failed

LibMambaUnsatisfiableError: Encountered problems while solving:
     - nothing provides desktop-app needed by runmanager-3.0.0rc1-py_0

Could not solve for environment specs
The following packages are incompatible
└─ labscript-suite is not installable because there are no viable options
├─ labscript-suite [3.0.0|3.0.0rc1|3.1.0|3.1.0rc1] would require
│ └─ runmanager but there are no viable options
│ ├─ runmanager [3.0.0|3.0.0rc1|3.0.0rc2|3.1.1] would require
│ │ └─ desktop-app, which does not exist (perhaps a missing channel);
│ └─ runmanager [3.2.0|3.2.0rc1|3.2.1] would require
│ └─ desktop-app >=0.1.2 , which does not exist (perhaps a missing channel);
└─ labscript-suite [3.2.0|3.2.0rc1] would require
└─ runmanager >=3.2.0 , which cannot be installed (as previously explained).

(labscript) treyporto@Treys-MBP ~ % _____________________________________________________________________

[the labscript suite]

Hi Trey,

I think the desktop-app dependency is on conda forge. I'm not sure why this problem is appearing now, but hopefully you just need to run 

conda config --add channels conda-forge

Hopefully the installation will be successful after that.

Cheers,

Phil 

[Trey Porto]

Hi Phil,

Thank you for your prompt reply.  Alas, your hopeful wishes for my speedy success did not come true.

I have a robust, consistent timeout error:

zlock log:
[2025-04-23 09:56:45,682] INFO logging to /Users/treyporto/labscript-suite/logs/zlock.log
[2025-04-23 09:56:45,683] INFO This is zlock server, running on tcp://*:7339
[2025-04-23 09:57:06,680] INFO [127.0.0.1] said hello
[2025-04-23 09:57:06,681] INFO [127.0.0.1] requested the protocol version

The zlock server starts, and when runmanager starts, the server clearly responds with "said hello" and "requested protocol version", but it always times out after that. The runmanager  log never gets written to.

I feel like the problem must be something simple that I'm just not getting, because it is robust against all of the things I have tried:

-- Python version (3.8, 3.9, 3.10, 3.11)
-- versions of zprocess and pyzmq (v>25 and v<25)
-- trying to resurrect a previously functional developer installation, or cloning a functional GitHub repository from our lab, or performing a fresh ("regular" or "developer") installation following instructions here:  https://labscriptsuite.org/en/latest/installation/

-- Based on the discussion here: https://groups.google.com/g/labscriptsuite/c/q_gMVD-W8hE/m/RLjPNbGHEAAJ,
I tried changing the ls_zprocess.py and outputbox.py files' bind_address() commands as suggested

-- based on past experiences, I tried changing localhost to 127.0.0.1 wherever I could find it.

-- I tried generated new secret keys

-- Tellingly, I tried setting allow_insecure=True and got the the same time-out behavior.

-- I've had experiences where an upgrade to MacOS intended to "enhance" security broke various things, but I haven't found anything like that.

Since it is a time-out error, there isn't much guidance as to what is causing the problem.  The fact that allow-insecure=True doesn't fix it must be telling me something.

Einstein said "The definition of insanity is doing the same thing over and over again and expecting different results"...   I think I am going insane, except that I am trying small variations of the same thing over and over again.

Cheers,
Trey

[dihm....@gmail.com]

Hi Trey,

Sorry this is proving so annoying! Installation fragility has been a somewhat recurring theme recently. I'm hoping to get some better automated testing going so we can catch these problems a bit easier. I have a couple questions and a couple suggestions (that you maybe have already tried). I'll be able to get my hands on a modern mac sometime later this week for more thorough testing if needed.

Questions:

1) What version of zeromq are you using? Could be worth downgrading it as well. We've had trouble with conda::defaults v 4.3.5 recently that they seem incapable of fixing.

2) Is your new mac arm based? Probably not super relevant, but it helps me replicate the environment better.

3) Assuming my suggestions below don't work, could you share a conda environment list and the OS-X version (again, to help replicate)?

Suggestions:

1) Have you been restarting the zlock/zlog servers between tests? It tends to linger once opened, even if packages are modified underneath, meaning the changes aren't actually propagated.

2) So I can't seem to find it right now but before the end of the day I'll track down a simple test script that unit tests zprocess communications separate from labscript stuff entirely. Running that would also help narrow down the source.

-David

[Trey Porto]

Hi David,

Thank you again for your prompt response.

Suggestion 2), the test script unit for zprocess would be extremely useful. Given that the behavior is just a timeout, I currently have no feedback information on what’s wrong. The next logical step would be to dive into the lower dungeons of labscript and track down exactly where the problem is, which I don’t really want to do. So I resorted to a random,  blind  hunt of input parameters (python version, zprocess version, allow_insecure setting etc.),  which is highly inefficient.

Questions:

1) zeromq version:  I tried so many different options, I’m not sure, and I removed all the unsuccessful conda environments once I determined that a particular combination of install parameters didn’t  work.  The one I last tried was zeromq 4.3.5. . I’m not sure how far back to go, but I’ll give it a shot.

2) yes, the new Mac is ARM based M3

3) macOS 14.7.5 (23H527). For the environment list, I will try to find some time later today to set up another environment.

Suggestions:

1) restarting zlock/zlog:  yes, I always kill zlock and zlog before trying again.  I even rebooted on several occasions to make sure.

2) as noted above, the test code would be useful.

Two things that I note about the behavior:

— zlog doesn’t add “hello” to the log until runmanager starts, so there is some communication happening.

— setting “allow_insecure = False”  doesn’t fix the problem, it also times out.

 

Cheers,

Trey

—
Dr. Trey Porto
Fellow, Joint Quantum Institute
National Institute of Standards and Technology
and the University of Maryland
College Park, MD 20742
UMD Office: PSC 2147
UMD Phone: 301-405-0854
Preferred e-mail: po...@jqi.umd.edu
Official NIST Business: tr...@nist.gov

--
You received this message because you are subscribed to a topic in the Google Groups "the labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/Z9CxnggHePo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuit...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/labscriptsuite/b1c74d7b-3e31-48dd-b124-289cf92c1b8an%40googlegroups.com.

[Jason Pruitt]

Hi Trey,

I've had success with a few recent labscript conda installs pinning zeromq==4.3.4, although I'm always doing the editable install. I believe it should be the same idea though, and if the issue is only with zeromq that's worked for me.

Some potentially relevant or helpful info here: https://groups.google.com/g/labscriptsuite/c/sr8x_K4MqHU/m/mBlilRaaAgAJ

Hopefully that helps,

Jason

[dihm....@gmail.com]

Trey,

Apologies for being slow. I couldn't find my script, but that is fine since Chris has a fairly complete test suite built into zprocess itself that is better.

To use the tests

1) clone down the zprocess repo (https://github.com/chrisjbillington/zprocess)

2) Install pytest and pytest-cov

3) From the zprocess parent directory, Install zprocess in editable mode:  `pip install -e . `

4) From the zprocess parent directory, Run `pytest`

Most (if not all) of these tests should pass and give decent confidence that zprocess is functioning properly on its own.

-David

[Trey Porto]

Thank you, David,

I finally had a chance to run the tests, and one of the 61 tests failed:

============================================= short test summary info =============================================

FAILED tests/test_zlog_server.py::ZLogServerTests::test_no_access - AssertionError: b'[Errno 13] Permission denied' not found in b"OSError: [Errno 30] Read-only file system: '/test.log'"

========================================== 1 failed, 60 passed in 26.65s ==========================================

_________________________________________ ZLogServerTests.test_no_access __________________________________________

self = <test_zlog_server.ZLogServerTests testMethod=test_no_access>

    @pytest.mark.skipif(os.name == 'nt', reason='Skip on Windows')

    def test_no_access(self):

        with self.client(None) as client:

            client.send_multipart([b'check_access', b'/test.log'])

>           self.assertIn(b'[Errno 13] Permission denied', client.recv())

E           AssertionError: b'[Errno 13] Permission denied' not found in b"OSError: [Errno 30] Read-only file system: '/test.log'"

tests/test_zlog_server.py:136: AssertionError

I haven’t had a chance to dig into it in depth, but I will investigate.

Cheers,

Trey

—
Dr. Trey Porto
Fellow, Joint Quantum Institute
National Institute of Standards and Technology
and the University of Maryland
College Park, MD 20742
UMD Office: PSC 2147
UMD Phone: 301-405-0854
Preferred e-mail: po...@jqi.umd.edu
Official NIST Business: tr...@nist.gov

To view this discussion, visit https://groups.google.com/d/msgid/labscriptsuite/4e1ecba7-c07a-4f9b-b573-7bb8a81168e6n%40googlegroups.com.

[dihm....@gmail.com]

Hmm. Well I'm on Windows so I don't get to run that test. I ended up with a different random failure that I chalked up to general randomness with my test environment.

```

self = <test_zprocess.HeartbeatTests testMethod=test_subproc_survives_until_kill_lock_released>

    def test_subproc_survives_until_kill_lock_released(self):
        _default_process_tree.heartbeat_server = self.mock_heartbeat_server
        self.process = HeartbeatClientTestProcess()
        to_child, from_child = self.process.start()
        # Wait for a heartbeat request:
        self.assertTrue(self.heartbeat_sock.poll(3000))
        # Tell child to acquire kill lock for 3 sec:
        to_child.put(None)
        # Don't respond to the heartbeat, process should still be alive 2 sec later
        time.sleep(2)
        # Process should be alive:
>       self.assertIs(self.process.child.poll(), None)
E       AssertionError: 15 is not None

tests\test_zprocess.py:302: AssertionError

```

In any case, I think your error may be a false positive, since the test is trying to confirm the file access is denied, you just got a slightly different error than what was expected.

Doing a small bit of digging on my test rig to try and give you a small head start:

1) It appears the runmanger log doesn't actually log very much on start (if anything). Only meaningful entries I see are when engage is called. So I wouldn't be too worried about seeing nothing in there.

2) Looking at my zlock.log, my next lock access is due to mainthread locking of the `.next_sequence_index`. This call comes from `__init__.next_sequence_index` via calls to `__init__.new_sequence_details` in `__main__`. It is highly likely that this is the lock event that is timing out on your end (for whatever reason).

3) Out of curiosity, are you using releases or the latest master branches for the install? If you aren't using the latest master branches, you might consider trying them. I doubt they fix the issue, but there is always a chance.

-David