We could add Slic3r, if it doesn't make the image considerably bigger I'd consider it. At least adding an installation script could totally work.
These are the instructions how to add it. I'm pretty busy, however pull requests are welcome.

@Penfold81 Some OctoPi installations might be used by any people and requiring them all to install Slic3r isn't convenient. Having it installed on the OctoPi can service all users.

For the same reason that it makes sense to have Cura installed by default, so might it make sense to have Slic3r installed.

I wouldn't go for pre-built binaries unless you maintain a deb package (which isn't much fun).
I'm willing to consider adding ot to the build if its not going to bloat up the image.

I support this, i and i suppose quite a lot of people prefer slic3r over cura. Some kind of script would make sense in my opinion.

Maybe two scripts, one for alexrj's original slic3r version and one for Prusa's version, when check is also well-developed.

Yeah i can't agree more, i think more choices is just going to attract more people to octopi.

Will users really want to log in to their raspberry pi and run a script?

I think they would if they want slic3r, as long as it's not a process that takes multiple hours.
I don't think they'd mind the extra few kilobytes for extra choices (in case they don't need slic3r) in octopi either.

@eyal0 for the first release, logging in via ssh to add Slic3r capability should be fine. OctoPi already enable SSH by default anyway, which is good. So I support some kind of installation script. But also if it can ship builtin OctoPi even better!

@ismangil But which slic3r version to include? alexrj or Prusa? I use Prusa's because I have a Prusa printer but both are actively developed. Either make sense.

If I had to choose one, alexrj. Good enough for most users like Cura 15. Advanced users will slice on PCs anyway.

But which slic3r version to include? alexrj or Prusa? I use Prusa's because I have a Prusa printer but both are actively developed. Either make sense.

I'd prefer Prusa's one as well, however i'd like it if we could just choose within the script/dialog. Would make most sense to me.

@eyal0 After going through both Slic3r/PE install instructions (you're right, it took hours), I ended up not trusting it, because there's a broken STL file that prints fine on the Cura plugin, yet prints out wrong on both Slic3r. Yes, of course any broken file should be fixed in netfabb or whatever, but the point is for some broken files Cura 15.04 can autorepair it. It just works.

Is it broken also when using slic3r on your desktop? If so, it might just be slic3r's problem. Slic3r isn't perfect.

I would love to be able to choose a Slic3r instead of Cura image. And the choice between PE vs Alexrj would also be really nice. I just installed it myself (which took a while) but I think I messed up my networking settings in the process. It would be nice to have a ready made image in case you decide to wipe it and start over.

What's the best way to do this? Including the script into OctoPi would be one way, but the script downloads the needed files and those files might change or be inaccessible.

How does OctoPi handle other things, like OctoPrint and cura? Are they included as binaries without requiring download or are they downloaded during the install process?

Cura is a plugin for OctoPrint. Up to now, it has been bundled with OctoPrint. I believe I read that Gina is planning on unbundling it (it will still be available as a user installed plugin). Because of how well OctoPrint interfaces with many modern desktop slicers, few people are actually using the outdated Cura plugin anyway. I'm doubting she is going to reverse herself and start bundling a slicer again. I'm betting she'll leave this to the plugin authors out there.

That would be a great solution, @guysoft . I'm still hoping that someday someone does an updated Cura plugin for OctoPrint

I think it might be a good idea to ship slicer installers.

This seems like a good idea to me. The script that I wrote isn't very stable, I worry, because it connects to servers that might or might not exist.

I do not have an RPi to test. If someone else wants to turn https://github.com/OctoPrint/OctoPrint-Slic3r/wiki/How-to-install-Slic3r-on-RPi into scripts that will install slic3r, I can try to help. Does someone want to do it?

We need someone to test it. I have no idea if it even works today because I haven't used it in a long time.

I suggest two scripts, one for Slic3r and one for Slic3r PE. Each should install to completely different directories so that people could potentially install both if they wanted. They should be pinned to a specific, known-working version to prevent errors. It should be easy to reclaim the disk space after so I suggest that all installing is done in subdirectories under a single directory, that way a single command can clean it all up.

Who will do this and test this? I don't have an RPi.

@eyal0 What I need to start, is a script I can push to /home/pi/scripts/install_slic3r.sh and also perhaps have a value to pick up other remotes (like PE).

I see instructions but no script.

If I paste it line by line I get:
https://gist.github.com/guysoft/6233e9911d6bd55e08e898732b29479a

I have a pi0w and micro sd cards in the mail. As soon as they arrive I might give your script a shot.

If I paste it line by line I get:
https://gist.github.com/guysoft/6233e9911d6bd55e08e898732b29479a

That script looks right but something is required after the second line to make it work. I have used a reboot but I think that there is another command that does not require a reboot that can be used.

According to this:

sudo /etc/init.d/dphys-swapfile stop
sudo /etc/init.d/dphys-swapfile start

Probably restart would do the same. So that line of the script needs adjusting.

Lines 12-77 are not needed for alexrj version. Those are just for slic3r Prusa edition (slic3r PE). The build can be a little faster without those lines.

I have a pi0w and micro sd cards in the mail. As soon as they arrive I might give your script a shot.

That would be good. Ideally you could take a fresh install of OctoPi and run the script on it. We should try to get the script to the point where it works smoothly on all devices. Both alexrj and slic3r PE.

I really don't have time to test these scripts, would appreciate is someone supplies something that was actually executed, and actually gave an output.

I have a pi0w and micro sd cards in the mail. As soon as they arrive I might give your script a shot.

That would be good. Ideally you could take a fresh install of OctoPi and run the script on it. We should try to get the script to the point where it works smoothly on all devices. Both alexrj and slic3r PE.

in the last two weeks I did some testing on my pi0w.
First I have to say, it is no fun to compile Slic3r on this thingy, so maybe the best would be to have some binary repository of some sort.
Build times for the alexrj version in master branch were around 24h for me. The PE fail roughly at 50% +-5 the longest build I let run was 72h, then canceled and tried to change something. On this one I tried master and 1.42.0_beta2 and 1.41.3 (which failed to clone from Github for some reason I have not researched for). Though the "master" seamed to fail during a general error in the branch, since there seams to be some work to be undergoing on the file structure of the project itself.

Maybe Prusa could provide ARM binaries, possibly even stripped down to only the libs and cli-tools needed for octoprint/octopi.

@VuiMuich I doub't pursa would provide arm builds.

Again, see my message above, would appreciate is someone supplies something that was actually executed, and actually gave an output.
If you can provide a build script, I can hold builds and binaries. I didn't get anything I can actually run yet from any of you, I only got a guide, thats not a script.

I just learned that the Slic3r PE build is failing because the libboost in stretch is only 1.62 but needs to be at least 1.64. (prusa3d/PrusaSlicer#1050)
Right now I am trying if upgrading to buster (where libboost is 1.68 I believe) would help.

I will try to put a script together from eyal0's guide for the alexrj version.

Hey, so I am considering adding this, mainly because the current cura is so old it won't compile on 64bit, and frankly I don't know who is using it. And I find that slic3r seems to be a better fit. And now with stronger Pis out there slicing on the device makes more sense in some cases.

@eyal0 is your script up to date? It needs to be converted to a module in order to be added in OctoPi.

@guysoft I don't know if it still works. I don't have a 3D printer at the moment unfortunately and I have no way to work on this nor test it.

Can you look through the issues and comments on Slic3r and see if someone has had success recently?

I just the other week went through the process of building Slic3r on my Pi 4. The guide at https://github.com/OctoPrint/OctoPrint-Slic3r/wiki/How-to-install-Slic3r-on-RPi did not work for me. What I ended up doing was building the dependencies using the makefile included with PrusaSlicer (https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Linux%20et%20al.md#dependency-resolution), then running Build.pl and following the rest of the normal build procedure (as detailed at the end of Build.pl). I did end up needing some additional libraries through apt as well.

@RyanMorash Can you list the commands you ran here by any chance to simplify the process of building a script. Moreover those instructions include the GUI side, we need a smaller part of that.

I’ll need to take a closer look as I can’t remember the exact steps I took. It looks like we could probably use these AppImage build scripts as a reference: https://github.com/davidk/PrusaSlicer-ARM.AppImage

FYI
OctoPrint/plugins.octoprint.org#1058