Add package managing capabilities

[NiklasRosenstein]

While it is already easy to just clone a repository with Git or even add it as a submodule, it would be even easier if you could issue a single command with Craftr to obtain the Craftfile (and the sources, if applicable). It could also be decouple from Git submodules as they can sometimes be a pain to manage.

While there could be commands to get a specific library/repository (eg. craftr get <module_name>), it would be very handy to have a file that lists all the dependencies. When you build with Craftr, it would make sure all dependencies are met and download them if any are missing.

[NiklasRosenstein]

I think with this, Craftr would become very similar to the way Go programs are compiled. Just that Craftr of course should work with any language.

[winksaville]

Love to see it.

On Wed, Feb 10, 2016 at 12:28 PM Niklas Rosenstein notifications@github.com wrote:

I think with this, Craftr would become very similar to the way Go programs are compiled. Just that Craftr of course should work with any language.

— Reply to this email directly or view it on GitHub https://github.com/craftr-build/craftr/issues/90#issuecomment-182570145.

[NiklasRosenstein]

It would need some kind of online repository though. :) Or maybe doing it the Brew way by hosting the information on GitHub. (information like where to get the source files and the Craftfile [which could eventually be different], version number etc.)

[NiklasRosenstein]

This is probably nothing I'll be able to implement this half of the year.

[NiklasRosenstein]

I'm thinking about an online repository for Craftfiles, similar to the Python Package Index for Python modules. This online repository would host all Craftr modules and make them available to be included in other projects by download or with Git submodules. Or, Craftr would download them as necessary.

It's not that simple however. Libraries can be built from source or using the system-wide installed shared libraries (eg. with pkg-config). Both should be supported, although eventually supported by different Craftfiles. So just for example, there would be a Craftfile to build libPNG from source and another to use the system-wide installed version of libPNG reading the configuration via pkg-config.

Which of these two version is used should be determined (or configured) at configure/compile time! Eg. on Windows, you will want to build a library like libPNG or ZLIB from source most of the time.

Also, a Craftfile that builds a library from source might only be compatible with one version, or a range of versions of that library. This must be specified with some meta information.

Another thing to consider is the source code required for the Craftfile. I don't think the Craftfile itself should implement retrieving the source code, rather a link to an archive of the source should be distributed along with the metadata or uploaded to the online repository alongside the Craftfile.

Dependencies Fileformat

I am thinking about a new filetype that specifies all the dependencies. Should a user want to reconfigure the dependencies, he will only have to touch this file which should be easy to edit. Eventually, there will be options to override dependencies via the command-line.

MODULE [== VERSION] [[TYPE]] [(CRAFTFILE VERSION)]

• MODULE – The name of the Craftr module
• VERSION – Version number of the library, == specifies the exact version, >= specifies the minimum version, etc. Defaults to the highest version number
• [TYPE] – This can be source or pkg-config or maybe other types we'll come up with, this decides which Craftfile to use.
• (CRAFTFILE VERSION) – The actual version number of the Craftfile, assuming there could be multiple versions for the same library version. Defaults to the highest version number that matches the VERSION. This version number would be enclosed in parenthesis to enhance readability. This version number can not be filtered with == or >=.

The TYPE default value would be different based on the platform. Eg. on Windows, TYPE would default to source while on Linux it would default to pkg-config.

Example

# Craftr dependencies file
lib.png >= 1.6.21 (1.2)
lib.zlib == 1.2.8 [source]

Metadata

A Craftfile in the online repository would require the following metadata:

{
  'name': 'lib.png',
  'type': 'source',
  'version': '>= 1.6 < 1.7',
  'craftfile_version': '1.2',
  'source_url': 'https://....',  # only for type "source" and if the source is not uploaded to the online repository
}

[winksaville]

Good idea, consider also the need for documentation and testing.

On Fri, May 27, 2016, 8:19 AM Niklas Rosenstein notifications@github.com wrote:

I'm thinking about an online repository for Craftfiles, similar to the Python Package Index for Python modules. This online repository would host all Craftr modules and make them available to be included in other projects by download or with Git submodules. Or, Craftr would download them as necessary.

It's not that simple however. Libraries can be built from source or using the system-wide installed shared libraries (eg. with pkg-config). Both should be supported, although eventually supported by different Craftfiles. So just for example, there would be a Craftfile to build libPNG from source and another to use the system-wide installed version of libPNG reading the configuration via pkg-config.

Which of these two version is used should be determined (or configured) at configure/compile time! Eg. on Windows, you will want to build a library like libPNG or ZLIB from source most of the time.

Also, a Craftfile that builds a library from source might only be compatible with one version, or a range of versions of that library. This must be specified with some meta information.

Another thing to consider is the source code required for the Craftfile. I don't think the Craftfile itself should implement retrieving the source code, rather a link to an archive of the source should be distributed along with the metadata or uploaded to the online repository alongside the Craftfile. Dependencies Fileformat

I am thinking about a new filetype that specifies all the dependencies. Should a user want to reconfigure the dependencies, he will only have to touch this file which should be easy to edit. Eventually, there will be options to override dependencies via the command-line.

MODULE [== VERSION] [[TYPE]] [(CRAFTFILE VERSION)]

• MODULE – The name of the Craftr module
• VERSION – Version number of the library, == specifies the exact version, >= specifies the minimum version, etc. Defaults to the highest version number
• [TYPE] – This can be source or pkg-config or maybe other types we'll come up with, this decides which Craftfile to use.
• (CRAFTFILE VERSION) – The actual version number of the Craftfile, assuming there could be multiple versions for the same library version. Defaults to the highest version number that matches the VERSION. This version number would be enclosed in parenthesis to enhance readability. This version number can not be filtered with == or >=.

The TYPE default value would be different based on the platform. Eg. on Windows, TYPE would default to source while on Linux it would default to pkg-config. Example

Craftr dependencies file

lib.png >= 1.6.21 (1.2) lib.zlib == 1.2.8 [source]

Metadata

A Craftfile in the online repository would require the following metadata:

{ 'name': 'lib.png', 'type': 'source', 'version': '>= 1.6 < 1.7', 'craftfile_version': '1.2', 'source_url': 'https://....', }

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/craftr-build/craftr/issues/90#issuecomment-222174632, or mute the thread https://github.com/notifications/unsubscribe/AA-hHOI0HGu54kgjX94Y8XfLbNGj0vz-ks5qFwt0gaJpZM4HXooi .

[NiklasRosenstein]

I started developing the craftr-web application.

[NiklasRosenstein]

Craftr 2.0 will come with a package manager ecosystem. Visit http://craftr.net/ for details