octoprint running on dietpi will not install plugin BGCODE about dietpi-docs HOT 5 OPEN

First of all, /etc/bashrc.d/dietpi-octoprint.sh is used to create the alias to call the OctoPrint CLI just via octoprint command, instead of manually using sudo and long paths. It runs on every interactive bash start, hence is not suitable for one-time actions, like installing build dependencies.

bgcode is an optional plugin, not preinstalled, is it? Generally it is expected that additional plugins may need additional build dependencies. Python wheels are compiled from source in those cases, no pre-compiled wheels hosted and downloaded. Only some are hosted as such on PyPI: https://pypi.org/project/OctoPrint-Wyze/#files

Further I adapted .bashrc in both /root and /home/dietpi and included a line:
export CXX=/usr/bin/gcc

That should not be needed since build-essential pulls not only gcc, but also g++, the C++ compiler this variable can define. And since C != C++, using the C compiler for C++ builds should usually fail. The variable for C is CC but should not be needed to be set manually either, since build tools else use the (correct) default paths.

Does the documentation for this plugin not contain the required compilers and headers to install/build it?

from dietpi-docs.

For doing forward with this:

bgcode is an optional plugin, not preinstalled, is it?

If it is pre-installed, we would need to fix it in dietpi-software. If it is a plugin one can install afterwards, we could add a tab to the docs which states that for such cases, additional compilers or development headers might be needed, and the official plugin repo/docs or install/error logs checked, to find out which (there is no generic "solution" in this case).

from dietpi-docs.

@MichaIng

If it is pre-installed,

No, it is not. binary gcode became a thing after octoprint, as such I can see why it was not in base octoprint. Still, given that many machines start to depend on it, I feel it should be supported. The other argument, is that "octopi" the Pi distro on which octoprint is installed, supports it which any special measures. From this perspective dietpi should mimic the same environment as octoprint: having an exception for one or more plugins is not logical from an octoprint user perspective where plugin installation should be straightforward and not require fiddling with the unix environment.

Having said all this: I am happy that I got everything working: dietpi is so much better! But at the same time I acknowledge that my steps to get it done are not optimal.

A simillar differce dietpi / octoprint is with respect to supporting webcams. I had to fiddle with that as well on dietpi.

from dietpi-docs.

From this perspective dietpi should mimic the same environment as octoprint

I wouldn't see it that way. The couter-argument is that we intentionally offer light and bare metal implementations of software, which is otherwise only available as pretty bloated full single-purpose OS images. Of course those images are more tailored and fully featured regarding this one software title, same like Home Assistant OS, LibreELEC and similar. Mimicing such cannot be a goal, but a minimal base installation in the first place, then considering each extension individually. There will always be more plugins available, this is why they are called "plugins".

having an exception for one or more plugins is not logical from an octoprint user perspective where plugin installation should be straightforward and not require fiddling with the unix environment.

That IMO is more a question about good documentation. Checking the docs: https://plugins.octoprint.org/plugins/bgcode/
Weird is that it covers the installation on Windows and Android only, not Linux. Likewise the GitHub repo: https://github.com/jneilliii/OctoPrint-BGCode

The other part is the OctoPrint install implementation. Not sure how it works and whether it has the infrastructure to take care about OS-based compiler/header dependencies as well.

Easiest would be of course if the project was on PyPI (Python Package Index), with pre-compiled wheels 🙂: jneilliii/OctoPrint-BGCode#12

For now I think we'll add a section in our docs, stating the matter of plugin build dependencies in general, with the example of BGCode. If there are more votes to have this added natively, I may consider it. I'd then add the plugin itself, not (only) the build dependencies.

from dietpi-docs.

@MichaIng

I wouldn't see it that way.

Well, I can for sure live with that. As long as people looking for a solution for BGCODE on a linux based implementation can find this information and learn about a solution. For me the solution above worked, I contacted jneilliii on this matter as to learn what could cause the problem I had. See: jneilliii/OctoPrint-BGCode#11 and my remarks (as ruedli). jneilliii wanted for practical reasons to limit his support for compilation to the platform offered by octopi. His criterium was that it should compile there and if it would not compile on e.g. linux that should be researched and resolved by others. I feel this is his good right: what he invested in code for octoprint is formidable and in my opinion a huge contribution to the community. What you are contributing in dietpi is of also of such nature. So I am totally okay when some effort is left for others to explore :-)

He did provide my remark on the solution also discussed here with a "like" in his closed issue.

AND... still enjoying my dietpi container with octoprint on my N100 -as we talk-: it really flies on this platform!

from dietpi-docs.