I've been working on a package manager (and libraries) for OpenSCAD for
a few months. I've done a lot of research on prior efforts and
experimented with several concepts. It's great that I'm not the only
one working on this issue!
scad_bundler is published at: https://github.com/lostapathy/scad_bundler
my first libraries are at: https://github.com/lostapathy/openscad-libs
an example project is at: https://github.com/lostapathy/scad_bundler_example
scad_bundler is built on top of Ruby, RubyGems and Bundler. If you have
Ruby installed, installation is as simple as "gem install
scad_bundler". It's compatible with all supported versions of Ruby. Mac
and Linux users should be fine with whatever version their OS packages.
At a high level:
-a project declares its dependencies inside a Scadfile
-the user directs scad_bundler to install them via 'scad_bundle install'
-the user starts openscad via 'scad_bundle exec openscad'
-scad_bundler constructs an appropriate OPENSCADPATH environment
variable to tell OpenSCAD where to find your libraries and launches
OpenSCAD.
Since it's built on top of RubyGems and Bundler, we get tons of
functionality for free. Most importantly:
- Robust version control. You won't have to upgrade your code just
because a library changed.
- The ability to publish your libraries as you see fit. You can push
your code to RubyGems, store it in a git repository, or just work from a
directory on your computer. Publish when (or if) you're ready, it's
your choice.
- We don't have to maintain any of the infrastructure or much software.
I've posted more about usage, design decisions, and conventions on the
GitHub repo. If you have questions or ideas, please email me or open an
issue.
Having this for the past couple months has been a total game changer for
me. It's taken a fair amount of work to extract the libraries I've
published, and they still aren't perfect. I plan to publish more
libraries and move into more complex objects - boxes, hardware, etc -
over time.
I'm super excited to see how this grows as we build farther above the
language primitives.
Joe
I've been working on a package manager (and libraries) for OpenSCAD for
a few months. I've done a lot of research on prior efforts and
experimented with several concepts. It's great that I'm not the only
one working on this issue!
scad_bundler is published at: https://github.com/lostapathy/scad_bundler
my first libraries are at: https://github.com/lostapathy/openscad-libs
an example project is at: https://github.com/lostapathy/scad_bundler_example
scad_bundler is built on top of Ruby, RubyGems and Bundler. If you have
Ruby installed, installation is as simple as "gem install
scad_bundler". It's compatible with all supported versions of Ruby. Mac
and Linux users should be fine with whatever version their OS packages.
At a high level:
-a project declares its dependencies inside a Scadfile
-the user directs scad_bundler to install them via 'scad_bundle install'
-the user starts openscad via 'scad_bundle exec openscad'
-scad_bundler constructs an appropriate OPENSCADPATH environment
variable to tell OpenSCAD where to find your libraries and launches
OpenSCAD.
Since it's built on top of RubyGems and Bundler, we get tons of
functionality for free. Most importantly:
1) Robust version control. You won't have to upgrade your code just
because a library changed.
2) The ability to publish your libraries as you see fit. You can push
your code to RubyGems, store it in a git repository, or just work from a
directory on your computer. Publish when (or if) you're ready, it's
your choice.
3) We don't have to maintain any of the infrastructure or much software.
I've posted more about usage, design decisions, and conventions on the
GitHub repo. If you have questions or ideas, please email me or open an
issue.
Having this for the past couple months has been a total game changer for
me. It's taken a fair amount of work to extract the libraries I've
published, and they still aren't perfect. I plan to publish more
libraries and move into more complex objects - boxes, hardware, etc -
over time.
I'm super excited to see how this grows as we build farther above the
language primitives.
Joe