I think that ultimately trying to really solve the three points you raise is
hard and will block meaningful progress.  We just need to ignore those
issues and try to press forward, or nothing is going to happen.

It seemed clear to me that hoping for consensus was too much.  As I noted,
there's a vocal group that thinks we don't need libraries and seems kind of
opposed to the idea.  They argue that it's easier to just write stuff from
scratch rather than learning to use a library.  The sort of library that
might interest that group of people (if you could find one) is going to be
quite different from the sort of library that I think we need.  When I
raised this issue a few months ago it was pretty clear that finding any kind
consensus was going to be impossible.  I decided that it made more sense to
try to build something good and hope that people would use it.

It seems that right now there is no good solution to the name space problem.
And it's only made worse by the fact that we can't use "use" due to its
performance problems.  However, there are also not tons of libraries, so in
some sense, the chance of conflict is low.  One way to avoid conflict is to
put everything into one big library and design it so there's no conflict,
which is the approach BOSL is taking, I would say.

Package management is a nice idea.  Especially if we had some sort of
automatic package fetching mechanism that would just install necessary
packages.  But that would have to be done outside of OpenSCAD and raises
more issues.  I think package management is also not really a major issue
until there are lots of libraries.  At least two package management
approaches have been suggested over the years.  But it seems like this
presents an extra hurdle and extra complication for just building support
for a core library.

In BOSL there is validation code.  I haven't looked at it and don't know how
it works.  The examples in the manual are all automatically generated from
comments in the code, which serves as another check on code validity.

capveg wrote

--
Sent from: http://forum.openscad.org/

You're right.  I don't mean to insult the people who wrote things ten years
ago that are in MCAD, or to suggest that this effort was wasted.  Part of
the challenge of library design is having a vision for how the base language
should be extended, and such ideas take time to develop, and experience.  We
benefit now from the last ten years of development.

--
Sent from: http://forum.openscad.org/

On Sat, Jun 1, 2019 at 4:28 PM Torsten Paul Torsten.Paul@gmx.de wrote:

There seems to be some confusion about which person in the thread you're
replying to.  I'm the one that suggested MCAD in the first place (not
dismissed it) and one of the people who has been trying to provide patches
to update it.  As I posted originally, it works for me if you work around
the well known bugs.  I'll say again: I'm happy to help make it better but
there is not a consensus as to how to do that.

• Rob
  .

On 2019-06-01 15:46, adrianv wrote:

I saw that discussion some time ago. Very odd.

Exactly.

To try to come up with "consensus" before something has been made is
usually a waste of time and will often drain away resources from useful
work. When good libraries appear they are useful regardless of
"consensus".

Libraries are meant to be a way of facilitating re-use of software
components. However, it is often forgotten that an ability to re-use
something is not the only requirement to a library. As Bjarne Stroustrup
once said: "For something to be re-usable, it must first be usable". It
may sound like a joke, but there are many "re-unusable" libraries in the
software world. It is harder to write a good re-usable library to be
used by many than to write a one-off piece of code.

The BOSL/BOSL2 libraries seem to be well documented, and that is one of
the most important aspects of making useful libraries.

If a library is found in a github repository, it can be cloned into a
location where the application can find it. That is for many practical
purposes a library package management system good enough.

Carsten Arnholm

I'm not sure why, both the forum post reference and the
quotes in the text show that this was a reply to the post
from adrianv.

I saw your references to the pull requests and it's great
to see those contributions. I did answer to your post
separately and I think I pretty much share your point of
view regarding libraries.

ciao,
Torsten.

On 6/1/19 9:33 AM, arnholm@arnholm.org wrote:

It's not just that they don't like the idea, it's that they're actively
hostile to the idea of libraries to the point I've talked to a handful
of people who wanted to get involved but stay away because of it.

It's really a shame.  A good library ecosystem detracts nothing from
users who don't want to use it, they can just continue to not use it. 
At the same time, there's very clearly a lot to be gained by some users
(and users who don't yet use OpenSCAD!) by having a good library ecosystem.

3. [didn't come up, but should have] How do we do name spacing,

My take in experimenting with this is that separate namespaces is less
of a show stopper than people think, assuming a couple things.

1)  You only have libraries you are using for the current project on
your OPENSCADPATH (like scad_bundler does)
2)  The libraries are well-structured so that you can "use" files that
only import the parts of the "public API" you need into your code and
don't require you to "include" a broad range of "internal functions" to
make them work.

I very much think we have all the pieces in place to build good, usable
libraries, but they are underutilized and under-contributed-to because
the prevailing method of "share it on thingiverse" is terrible for
distribution, updates, and collaboration.  Because of that, we haven't
really figured out, as a community, "best practices" for making great
libraries that are heavily useful and reusable.

Another aspect to this is frameworks. My own library is set up for
automation with Python scripts. It makes BOMS, stl files, dxf files,
assembly diagrams and build documentation like the Mendel90 build manual,
which was largely manual but is now automated  for every new project I make
using Markdown fragments in the OpenSCAD comments.. For that to work it has
lots of conventions and a very particular coding style. For example any
module that makes and stl must be called something_stl() and call a module
stl("something"). Then it appears on the BOM, gets generated automatically
and rendered for the build instructions.

For example this code:
//
//! * Attach the four feet using 10mm M3 dome screws, washers above and
below and nyloc nuts
//
module feet_assembly()
assembly("feet") {
base_assembly();

foot_positions()
    foot_assembly(base_thickness, foot);

}

Generates this:
Feet AssemblyVitamins
QtyDescription
8 Washer M3 x 7mm x 0.5mm
4 Screw M3 dome x 10mm
4 Nut M3 nyloc3D Printed parts
4 x foot.stl

[image: foot.png]
Sub-assemblies
1 x base_assembly

[image: base_assembled_tn.png]
Assembly instructions
[image: feet_assembly.png]

• Attach the four feet using 10mm M3 dome screws, washers above and
  below and nyloc nuts

[image: feet_assembled.png]

For that reason I could never use anybody else's library. For example if I
wanted an involute gear I wouldn't use MCAD because it wouldn't fit in my
framework. I would look up the maths and write my own, so that any gears I
designed got added to the BOM, STL file automatically generated and
rendered into the build instructions. The only reason I haven't done that
is because I haven't designed anything with gears in it. My own library
only has things I have used, nothing more, nothing less.

On Sat, 1 Jun 2019 at 18:18, Joe Francis joe@lostapathy.com wrote:

I use InkScape to trace the edges and use the OpenSCAD plugin on
Thingiverse to output a polygon in OpenSCAD source format.

On Sun, 2 Jun 2019 at 15:18, jon jon@jonbondy.com wrote: