Added DLL Path Argument

[bemcdonnell]

Very simple adjustment to the Simulation class so we can point to custom DLLs

[michaeltryby]

The dll path should be handled for the programmer by the pyswmm object. The user of the simulation object shouldn't have to worry about it. Separation of concerns. If the programmer wants to point to a custom dll perhaps there is a better way.

One idea would be to instantiate the pyswmm object with the path to the dll and then pass it to the Simulation constructor. So you would make the pyswmm object as argument of the simulation constructor instead of the dll path. Make sense?

I think this is a better solution, but I'm sure there are even better ones I may not be aware of.

[bemcdonnell]

@michaeltryby, there is a default path that is handled "behind the scenes." But if the user wants to specify their own version of the dll, this is an option. In the module PySWMM, the user already has the option to point to their DLL of choice. within Simulation object, I wanted to extend that capability

[michaeltryby]

@bemcdonnell I understand that and I don't think it should be done that way. Responsibility for the dll path should be contained within the pyswmm object. My suggested solution accomplishes that.

[bemcdonnell]

@michaeltryby, that's a fair point...

@goanpeca, what do you think?

[michaeltryby]

@bemcdonnell @goanpeca Just brainstorming .... You could make the pyswmm object "smarter" about managing the dll path. For example, designate a location for alternate dlls and have the pyswmm object look there.

A python wrapper pointing at a dll is standard stuff. I'm sure this has been solved really well by someone else.

[goanpeca]

I don't like the idea of having a dll_path. This should be handled automatically.

[bemcdonnell]

Any user-defined DLL path is more for power users. 99/100 times users will not need to do anything with this. Regardless of how we do this, I have identified a case where I need this feature. In my case, the swmm5.DLL has other DLL dependencies that may or may not be registered in the system PATH. For this configuration to work, I am placing my SWMM.DLL and its dependencies within my working directory. Then, at least how it is configured in the PR, I am pointing to the DLL in my working directory. Not the most beautiful solution but works reasonable well.

[michaeltryby]

This is a fine feature to add. What we are saying is "Lets think about how we do this." How we implement this matters. If 99/100 users won't use this then by definition it should not be a function argument.

@bemcdonnell Based on how you are using this, I think a better solution would be for the pyswmm object to automatically scan the working directory for an alternate dll and if one isn't found revert to the dll installed with the pyswmm package in site_packages. Make sense?

This is a win, win solution. You get the functionality you want, the dll path is managed, and the concern about dll path stays separated from the Simulation object because it doesn't belong there.

[bemcdonnell]

We should come back to this. :-)