Allow options to be passed through in Pkg.build

[dpsanders]

We should allow Pkg.build (or the equivalent in Pkg3) to pass through keyword arguments to the package it's building, to be able to do e.g.

Pkg.build("IJulia", jupyter=false)

[tkelman]

What would they translate to? It's a separate julia process so it's not sharing variables, and there's no requirement for deps/build.jl scripts to contain anything specific.

[dpsanders]

On Tue, Jan 17, 2017 at 10:44 AM, Tony Kelman ***@***.***> wrote: What would they translate to? It's a separate julia process so it's not sharing variables, and there's no requirement for deps/build.jl scripts to contain anything specific.

Maybe there should be by default a `build()` function in `deps/build.jl` that can accept keyword arguments.

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20082 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALtToLQFyyv-QTa6gw5HL84B_3Ik7tSks5rTCr5gaJpZM4LlKYU> .

-- Dr. David P. Sanders Profesor Titular "B" / Associate Professor Departamento de Física, Facultad de Ciencias Universidad Nacional Autónoma de México (UNAM) dpsanders@g <dpsanders@ciencias.unam.mx>mail.com / Twitter: @davidpsanders <https://twitter.com/DavidPSanders> http://sistemas.fciencias.unam.mx/~dsanders / GitHub: dpsanders <https://github.com/dpsanders> Cubículo / office: #414, 4o. piso del Depto. de Física Tel.: (+52 55) 5622 4965

[tkelman]

I'd personally like to move away from executing a script at package install time, and entirely encode things to download, library dependency versions etc in a set of standardized toml files. I think Stefan has something like that in mind for package configuration options, if you check the Pkg3 julep.

[dpsanders]

Sure, sounds good.

My point is just that there should be the possibility of the user choosing configure options for the build in different ways, e.g. by keyword arguments at the time you download / build the package.

An example is the one I gave, where IJulia.jl can either use a local Jupyter installation, or download its own -- this is a user choice that should be easily configurable.

[maleadt]

I'd be interested in such functionality. Right now, I use environment variables for this purpose, eg. LLVM.jl's build.jl listens to USE_SYSTEM_LLVM, LLVM_VER, etc.

[chakravala]

This would also be useful for my package Reduce.jl, which depends on the download and installation of an externally distributed library. There are actually 2 different versions of the library CSL & PSL reduce (one has better UTF8 support but the other is more portable). If there was an option in the build system, the user could specify which version to download using the build command.

At the moment, I am relying on environment variables to detect this as well.

[oschulz]

Enviroment variables may be the better solution here, as the user may not trigger Pkg.build directly, or may not always remember which options to pass. Environment variables allow for external control - this is especially useful in a multi-user context (resp. a situation where users live in a predefined environment and may not need/want to know about build options for individual packages). Also in software containers (Docker & Co. all have good management for environment variables), explicit Pkg.build options will be more difficult to set consistently.

[simonbyrne]

I think the eventual plan with the new Pkg is to do this as part of the config, see JuliaLang/Pkg.jl#458