Workbench-Starterkit refactor

[triplus]

Yes, if there is a better way to handle this in ubuntu/debian then we should try it. I guess we simply have to define some standards for interfaces which can be fulfilled by any distro in one way.

Likely it's the other way around. Much researching and adapting to existing Python, Linux, macOS and Windows software packaging standards.

[looo]

Yes, if there is a better way to handle this in ubuntu/debian then we should try it. I guess we simply have to define some standards for interfaces which can be fulfilled by any distro in one way.

Likely it's the other way around. Much researching and adapting to existing Python, Linux, macOS and Windows software packaging standards.

For the python interface, we have the opportunity to define this by ourselves. For the command-line-interface, we haven't aligned to Debian rule to have all-lower-case (freecad) for commands. I don't know if this is by design or if this is by accident, so I went with upper-case (FreeCAD) for conda.

To me, it makes sense if the build-output is uppercase. This way one can distinguise between a system command and a local build. So my suggestion would be to go for lower-case if it's an official version from any distro and use uppercase for the local build.

[vocx]

... So my suggestion would be to go for lower-case if it's an official version from any distro and use uppercase for the local build.

Are you talking about the compiled libraries or about the executable? Because what you want already exists for the executables.

In Ubuntu the stable executables are freecad and freecadcmd; in the version compiled from source, these are FreeCAD and FreeCADCmd.

But in both cases the libraries are FreeCAD.so, FreeCADGui.so, etc.

[looo]

... So my suggestion would be to go for lower-case if it's an official version from any distro and use uppercase for the local build.

Are you talking about the compiled libraries or about the executable? Because what you want already exists for the executables.

In Ubuntu the stable executables are freecad and freecadcmd; in the version compiled from source, these are FreeCAD and FreeCADCmd.

But in both cases the libraries are FreeCAD.so, FreeCADGui.so, etc.

Yes I am talking about the executables. In windows and mac lower and upper-case doesn't matter. So freecad and FreeCAD refer to the same command.
As I like this debian rule, have also switched conda to lower-case. But making this a FEP will help newcomers to make the right decision. So I will prepare a FEP for this. Whoever thinks he knows better how to deal with this, feel free to criticize in the corresponding PR.

Hopefully, this topic finally can return to the things it addresses (Workbench-Starterkit).

[vocx]

Ah I see, this is daily build (lower-case) vs stable build (upper case) and another example of a workaround for the multiple versions in one system problem and not a debian rule?

Sorry, you lost me. The stable package is also in lowercase. I don't know what the Debian policies are.

Code: Select all

ls -l /usr/bin/freecad*
lrwxrwxrwx 1 root root 25 Jul 31 10:42 /usr/bin/freecad -> /etc/alternatives/freecad*
lrwxrwxrwx 1 root root 28 Jul 31 10:42 /usr/bin/freecadcmd -> /etc/alternatives/freecadcmd*
lrwxrwxrwx 1 root root 34 Oct 29 13:51 /usr/bin/freecadcmd-daily -> /etc/alternatives/freecadcmd-daily*
lrwxrwxrwx 1 root root 31 Oct 29 13:51 /usr/bin/freecad-daily -> /etc/alternatives/freecad-daily*

Debian/Ubuntu uses the "alternatives" system to choose the correct executable.

Code: Select all

ls -l /etc/alternatives/freecad*
lrwxrwxrwx 1 root root 36 Jul 31 10:42 /etc/alternatives/freecad -> /usr/lib/freecad/bin/freecad-python3*
lrwxrwxrwx 1 root root 39 Jul 31 10:42 /etc/alternatives/freecadcmd -> /usr/lib/freecad/bin/freecadcmd-python3*
lrwxrwxrwx 1 root root 45 Oct 29 13:51 /etc/alternatives/freecadcmd-daily -> /usr/lib/freecad-daily/bin/freecadcmd-python3*
lrwxrwxrwx 1 root root 42 Oct 29 13:51 /etc/alternatives/freecad-daily -> /usr/lib/freecad-daily/bin/freecad-python3*
lrwxrwxrwx 1 root root 28 Jul 31 10:42 /etc/alternatives/freecadlib -> /usr/lib/freecad-python3/lib/
lrwxrwxrwx 1 root root 34 Oct 29 13:51 /etc/alternatives/freecadlib-daily -> /usr/lib/freecad-daily-python3/lib/

You could launch /usr/lib/freecad/bin/freecad-python3 directly, but with the alternatives system, it is provided as /usr/bin/freecad.

[looo]

Ah I see, this is daily build (lower-case) vs stable build (upper case) and another example of a workaround for the multiple versions in one system problem and not a debian rule?

Sorry, you lost me. The stable package is also in lowercase. I don't know what the Debian policies are.

Code: Select all

ls -l /usr/bin/freecad*
lrwxrwxrwx 1 root root 25 Jul 31 10:42 /usr/bin/freecad -> /etc/alternatives/freecad*
lrwxrwxrwx 1 root root 28 Jul 31 10:42 /usr/bin/freecadcmd -> /etc/alternatives/freecadcmd*
lrwxrwxrwx 1 root root 34 Oct 29 13:51 /usr/bin/freecadcmd-daily -> /etc/alternatives/freecadcmd-daily*
lrwxrwxrwx 1 root root 31 Oct 29 13:51 /usr/bin/freecad-daily -> /etc/alternatives/freecad-daily*

Debian/Ubuntu uses the "alternatives" system to choose the correct executable.

Code: Select all

ls -l /etc/alternatives/freecad*
lrwxrwxrwx 1 root root 36 Jul 31 10:42 /etc/alternatives/freecad -> /usr/lib/freecad/bin/freecad-python3*
lrwxrwxrwx 1 root root 39 Jul 31 10:42 /etc/alternatives/freecadcmd -> /usr/lib/freecad/bin/freecadcmd-python3*
lrwxrwxrwx 1 root root 45 Oct 29 13:51 /etc/alternatives/freecadcmd-daily -> /usr/lib/freecad-daily/bin/freecadcmd-python3*
lrwxrwxrwx 1 root root 42 Oct 29 13:51 /etc/alternatives/freecad-daily -> /usr/lib/freecad-daily/bin/freecad-python3*
lrwxrwxrwx 1 root root 28 Jul 31 10:42 /etc/alternatives/freecadlib -> /usr/lib/freecad-python3/lib/
lrwxrwxrwx 1 root root 34 Oct 29 13:51 /etc/alternatives/freecadlib-daily -> /usr/lib/freecad-daily-python3/lib/

You could launch /usr/lib/freecad/bin/freecad-python3 directly, but with the alternatives system, it is provided as /usr/bin/freecad.

sry, I modified my post after realizing that I misinterpreted your post. So all lower is the debian policy I guess.

[vocx]

...

Hopefully, this topic finally can return to the things it addresses (Workbench-Starterkit).

Unfortunately, this is in the Announcement section. Moderators don't like announcement threads to be long and full of discussions, so this will have to be moved to the Open Discussion section, or be locked.

Sorry Joel.

[chrisb]

This topic fits indeed very well in the Open discussion forum, I moved it.

[midgetfc]

Hello,
I would like to mention an alternative to provide the version string for the package.

You are clearly in a setuptools packaging context.
So, in my humble opinion, the most natural place for package version info is in the 'version' named argument to setup function.
(I think it stands also for the rest of package metadata info).

If you only need to include this version info in one unique place in the package, it's done. (eg for a pure python package)

If you need this version info somewhere else in your packaging process, setuptools documentation suggests to put package metadata in a setup.cfg file along the setup.py script.
(note that it's optional. The setup.cfg info is read after the named parameters to setup(), and before any options passed on the command line)

Thus, the setup.py plumbing is separated from metadata informations like description, maintainer, etc...

More important, this metadata is accessible as a dictionnary in python from your setup.py script with setuptools.config.read_configuration(<path_to_setup.cfg>) .

Now, you can use it to generate a 'version.py' or 'version.h' or anything you need for your package.
This is not really relevant for simple pure python packages, but becomes necessary if you extend setuptools with custom comands, to add a module as a compiled extension for example.

[vocx]

So I've been playing with the Workbench-Starterkit code for a few months. I really love the new design. It's cleaner and more organized and I think it's poised to be one of the nicest development tools that we can offer new FC devs / superusers.

...

I'm also interested in seeing more uniform workbench layout across FC workbenches, both internal and external, as @vocx is attempting to do with the Draft WB.
...

I'm bumping this thread because we have made further progress with Draft's re-organization.

[Discussion] Splitting Draft tools into their own modules

This post shows an updated diagram of the work, which must be updated further.