packaging system, versioning?

[donbright]

i was just curious if any of your work had explored into the idea of a packaging system and/or versioning system?

pretty much every language and/or system i have looked at recently has a packaging / distribution system, including

Go (go fetch, also can include modules using URLs) Haskell (cabal) Node.js (npm) Ruby (gems, others) Python (pip) Perl (CPAN) R (CRAN, and within R, something called "devtools" which can pull directly from github) MSYS2 (pacman, ported from Arch Linux)

With OpenSCAD it appears we are currently stuck with "Go to thingiverse... download a zip file... unzip it... open the folder, copy the file to your project subdirectory, no, you need the newer version, go to the github, get the file off of the designer's github.. )

[doug-moen]

I've thought about creating a packaging system like Haskell, Ruby, Python, etc. That involves setting up and maintaining a centralized repository, finding volunteers to run the repository, and convincing people to submit their code to the repository, which isn't my favourite solution to the problem.

I've also thought about allowing URLs to be used with 'use' and 'include' statements, and I like that idea better, since it's decentralized, and compatible with source files already existing on thingiverse and github. Eg,

include https://www.thingiverse.com/download:1573147

use <https://raw.githubusercontent.com/openscad/scad-utils/master/lists.scad

On 3 September 2015 at 18:54, don bright notifications@github.com wrote:

i was just curious if any of your work had explored into the idea of a packaging system and/or versioning system?

pretty much every language and/or system i have looked at recently has a packaging system, including

Go (go fetch, also can include modules using URLs) Haskell (cabal) Node.js (npm) Ruby (gems, others) Python (pip) Perl (CPAN) R (CRAN, and within R, something called "devtools" which can pull directly from github) MSYS2 (pacman, ported from Arch Linux)

With OpenSCAD it appears we are currently stuck with "Go to thingiverse... download a zip file... unzip it... open the folder, copy the file to your project subdirectory, no, you need the newer version, go to the github, get the file off of the designer's github.. )

— Reply to this email directly or view it on GitHub https://github.com/doug-moen/openscad2/issues/19.

[donbright]

any thoughts on dependencies? (what happens if you include something that includes something that includes something...)

[doug-moen]

I haven't worked out all the details and consequences of referencing external source files using URLs.

The existing 'include' statement already supports including something that includes something. So that should just work. A recursive loop in the dependency tree is a problem, and should be reported as an error. Was there some other issue you were thinking of?

If we support URLs, then you'd like to be able to use them in all of the functions that take filenames as arguments. For example, import(filename).

If we support URLs, then it would be quite useful to support relative URLs, just like in HTML. Relative URLs can look just like file system pathnames, so then you would need to introduce the "file:" URL scheme to distinguish filenames from relative URLs. But if we are extending import() et al to support URLs, then we need to worry about backward compatibiity.

So, this proposal raises multiple issues that would need to be resolved.

On 4 September 2015 at 20:17, don bright notifications@github.com wrote:

any thoughts on dependencies? (what happens if you include something that includes something that includes something...)

— Reply to this email directly or view it on GitHub https://github.com/doug-moen/openscad2/issues/19#issuecomment-137886311.

[donbright]

thanks, mostly i was just curious. want me to close this issue?