Just grab the transition tool package, at version 2.1.1 which I just released this morning after some cleanups.

When do we start using https://github.com/Myoldmopar/EnergyPlusPythonApps/ as a meta package itself?

• Update requirements.txt for energyplus-transition-tools Myoldmopar/EnergyPlusPythonApps#6

If the auxiliary updater keywords are passed to the E+ CLI, it will launch the transition GUI and leave. This could be modified later to like pass the IDF file in, but I truly don't think that's necessary. This is launching a GUI, no one should be integrated this auxiliary argument into some sort of automated workflow.

And yes, there is quite a bit of duplicate from the EP Launch code right above. Would be nice to collect things into the PythonEngine class and out of here. But doesn't have to be right now.

If the auxiliary updater keywords are passed to the E+ CLI, it will launch the transition GUI and leave. This could be modified later to like pass the IDF file in, but I truly don't think that's necessary. This is launching a GUI, no one should be integrated this auxiliary argument into some sort of automated workflow.

It'd sure be nice if one could bypass the GUI and do something like energyplus auxiliary updater myfile.idf (potentially with a --up-to-version 24.2.0) to directly transition the file in the command line.

Yes, that would be great, let's do that soon.

The IDFVersionUpdater shortcut is not there. Does it need a line like this one?

Oh sheesh. Yes. I've got another round of tweaks on the updater tool itself that I'm wrapping up and will tag/pin a new version, and update this here.

I think I'll plan on just naming this info.plist.in since it becomes info.plist.

What extra args does this accept? I'm confused.

It doesn't...for now. This could be considered future proofing and not hurt anything right now.

If the auxiliary updater keywords are passed to the E+ CLI, it will launch the transition GUI and leave. This could be modified later to like pass the IDF file in, but I truly don't think that's necessary. This is launching a GUI, no one should be integrated this auxiliary argument into some sort of automated workflow.

It'd sure be nice if one could bypass the GUI and do something like energyplus auxiliary updater myfile.idf (potentially with a --up-to-version 24.2.0) to directly transition the file in the command line.

I think you need to sign the .app bundle itself.

I don't think bash scripts really need to be signed?

In any case, your launcher.sh If I'm reading this PR correctly does NOT live at INSTALL_PATH/launcher.sh but at INSTALL_PATH/AppName.app/Contents/MacOS/launcher.sh, right?

I think you're perhaps going about it the wrong way.

First, on mac, what we do is to:

• Copy the tcl libs
• Use install_name_tool to change the _tkinter.so so look for these libs and NOT at /opt/homebrew/xxxx . See cmake/PythonFixUpTclTk.py
• That way no need to mess with the LD_LIBRARY_PATH or anything

So at the very least, you should probably do the same with Linux.

(py312)(3.2.2)julien@EnergyPlus-build-release$ ldd Products/python_lib/lib-dynload/_tkinter.cpython-312-x86_64-linux-gnu.so
	linux-vdso.so.1 (0x0000734351f28000)
+	libtk8.6.so => /lib/x86_64-linux-gnu/libtk8.6.so (0x0000734351d84000)
+	libtcl8.6.so => /lib/x86_64-linux-gnu/libtcl8.6.so (0x0000734351bd7000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000734351800000)
	libXft.so.2 => /lib/x86_64-linux-gnu/libXft.so.2 (0x0000734351bbc000)
	libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x0000734351b6b000)
-	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x0000734351a2c000)

But Honestly, I don't see why we should ship libtk/libtcl any more than libX11 for eg.

On mac, there is a difference:

1. You must have brew installed to brew install tcl-tk . Ubuntu users have apt already.
2. The newest brew recipe is incompatible, you have to specifically call brew install tcl-tk@8
   • cf https://formulae.brew.sh/formula/tcl-tk

FWIW, in OpenStudio when we build the .deb installer, we do set the dependencies that are missing in E+:

https://github.com/NREL/OpenStudio/blob/98207d21649408d964fbc2660110a4cbdb35eb7d/CMakeLists.txt#L1264

set(CPACK_DEBIAN_PACKAGE_DEPENDS "libgomp1, libx11-6") # This is for EnergyPlus

One of my main goals is to continue to allow a non-sudo install of EnergyPlus on Linux. If the user doesn't want system symlinks, and wants to install it in a user-owned folder, they shouldn't need to follow up with sudo installing stuff. I am not going to die on that hill, but I will risk being injured on it. I have it working really well, so I think we should put 25.1 out there with this, and we can make a correction if needed as we go into the next version.

OK, so I'll do a walkthrough now. There are still a couple things left but it's very very close.

Thanks to @jmarrec for getting these Python app bundles signed and packed up nicely. Things are working amazingly on Mac. I imagine we will want more of these as we add a few more apps (EpJSONEditor...)

Alright, so here is a new QtIFW script that is attached to the Unspecified component. Could consider adding it to the Auxiliary or something if we wanted all the Python CLI app stuff in Auxiliary.

Anyway, this script will handle any desktop integration steps to enhance the user experience.

Now that we are packaging up the tcl and tk stuff for Ubuntu, we need to abort if we are not on one of those (so .... Windows 🙃 )

If we are on Mac, we haven't changed anything from 24.2. We still find the tk blobs, move things around, and run install_name_tool to get everyone happy.

On Linux, we are currently getting the libtk library, plus the tcl and tk config/data directories and bringing them along. As it stands right now, on Linux you need to tell the process where to find libtk8.6.so in order to run the Python GUIs. This is hidden from the user through the desktop integration and setting LD_LIBRARY_PATH. But @jmarrec feels we should do a patchelf to fix up the _tkinter library instead. I'm on board, and this will likely be fixed up before merge. I will say, it does seem like everything is running happily though.

Indeed the patchelf stuff worked! Note that when you apt install python3-tk, you will get a _tkinter shared object library that is stripped of it's ELF section headers, and you cannot write an rpath into it. A warning has been added to GHA if it encounters this condition.

On Linux we now need to create a couple shell scripts to launch EPLaunch and VersionUpdater right in the install root. On second thought, maybe these aren't needed? I'll consider removing them.

And we also now install a .desktop template inside install root / share/applications to be customized at install time by the QtIFW scripts.

I decided to leave these little shortcuts in. I honestly doubt many people will ever use them on Linux. Either they will be happy on a terminal and just execute ./energyplus auxiliary eplaunch, or they will use the desktop integration and click on the E+ icon on the dock. But it's fine for now.

It doesn't...for now. This could be considered future proofing and not hurt anything right now.

Yes, that would be great, let's do that soon.

I was duplicating this for each GUI, so I made a worker function out of it.

This is the worker function on Windows that can execute a script without opening a terminal. The shenanigans are at a all time high, but this works so perfectly. I'm quite happy with it.

One could argue you should be using std::filesystem::path (which uses wchar_t on windows), instead of string manipulation. But you're already using Windows API, so screwed for screwed 🤷

https://godbolt.org/z/G1Ydo6qEz

I think you could call GetLastError to format the system error message. Untested:

diff --git a/src/EnergyPlus/WindowsGuiLauncher.cc b/src/EnergyPlus/WindowsGuiLauncher.cc
index 8d63d8b3f1..b8a007275a 100644
--- a/src/EnergyPlus/WindowsGuiLauncher.cc
+++ b/src/EnergyPlus/WindowsGuiLauncher.cc
@@ -45,30 +45,53 @@
 // OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 // POSSIBILITY OF SUCH DAMAGE.
 
+#include <filesystem>
 #include <string>
 #include <windows.h>
 
+void ErrorExit()
+{
+    // Retrieve the system error message for the last-error code
+
+    LPVOID lpMsgBuf;
+    DWORD dw = GetLastError();
+
+    if (FormatMessageW(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
+                       NULL,
+                       dw,
+                       MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+                       (LPWSTR)&lpMsgBuf,
+                       0,
+                       NULL) == 0) {
+        MessageBoxW(NULL, TEXT("FormatMessage failed"), TEXT("Error"), MB_OK);
+        ExitProcess(dw);
+    }
+
+    MessageBoxW(NULL, (LPWSTR)lpMsgBuf, TEXT("Error"), MB_ICONERROR | MB_OK);
+
+    LocalFree(lpMsgBuf);
+    ExitProcess(dw);
+}
+
 int wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow)
 {
+    using namespace fs = std::filesystem;
+
     // Get the path of the current executable
-    wchar_t path[MAX_PATH];
-    if (GetModuleFileNameW(NULL, path, MAX_PATH) == 0) {
+    wchar_t c_path[MAX_PATH];
+    if (GetModuleFileNameW(NULL, c_path, MAX_PATH) == 0) {
         MessageBoxW(NULL, L"Failed to get module file name!", L"Error", MB_ICONERROR | MB_OK);
         return 1;
     }
 
     // Remove the executable name to get the directory
-    std::wstring directory(path);
-    size_t pos = directory.find_last_of(L"\\/");
-    if (pos != std::wstring::npos) {
-        directory = directory.substr(0, pos); // Extract just the directory path
-    }
+    fs::path thisExePath(c_path);
+    fs::path thisDirPath = thisExePath.parent_path();
 
     // Construct the target application path (assuming it's in the same directory)
-    std::wstring targetApp = directory + L"\\energyplus.exe";
+    fs::path targetApp = thisDirPath / L"energyplus.exe";
 
-    // Check if the file exists
-    if (GetFileAttributesW(targetApp.c_str()) == INVALID_FILE_ATTRIBUTES) {
+    if (!fs::is_regular_file(targetApp)) {
         MessageBoxW(NULL, L"Application not found!", L"Error", MB_ICONERROR | MB_OK);
         return 1;
     }
@@ -78,19 +101,19 @@ int wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int
     args += lpCmdLine;
 
     // Launch the target application
-    HINSTANCE hInstance2 = ShellExecuteW(NULL,              // Parent window
-                                         L"open",           // Operation
-                                         targetApp.c_str(), // Executable path
-                                         args.c_str(),      // Arguments
-                                         directory.c_str(), // Working directory
-                                         SW_HIDE            // Hide console
+    HINSTANCE hInstance2 = ShellExecuteW(NULL,                // Parent window
+                                         L"open",             // Operation
+                                         targetApp.c_str(),   // Executable path
+                                         args.c_str(),        // Arguments
+                                         thisDirPath.c_str(), // Working directory
+                                         SW_HIDE              // Hide console
     );
 
-    // Error handling
+    // Error handling: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew#return-value
     if ((intptr_t)hInstance2 <= 32) {
         std::wstring errorMsg = L"Failed to launch application! Error code: " + std::to_wstring((intptr_t)hInstance2);
         MessageBoxW(NULL, errorMsg.c_str(), L"Error", MB_ICONERROR | MB_OK);
-        return 1;
+        ErrorExit();
     }
 
     return 0;

Deferring this until later, but very happy to get this tested and integrated later.

Patchelf is used to edit the ELF header in the _tkinter shared object library on Linux, similar to install_name_tool on Mac.

Removed the IDFVersionUpdater for Linux....Windows and Mac are going to be gone with the next release.

Indeed the patchelf stuff worked! Note that when you apt install python3-tk, you will get a _tkinter shared object library that is stripped of it's ELF section headers, and you cannot write an rpath into it. A warning has been added to GHA if it encounters this condition.

I would like to move these to regular CMake messages instead of print statements.

CLEAN little desktop file. :)

Even added an uninstall step to clean up the .desktop file path.