juliapackaging / bindeps.jl Goto Github PK

Remove mention in README and references in code to Pkg2.markworking

E.g., nettle isn't available through the standard repos on Centos 6, so it bails with

julia> Pkg.add("Nettle")
INFO: Cloning cache of Nettle from git://github.com/staticfloat/Nettle.jl.git
INFO: Installing Nettle v0.0.0
INFO: Running build script for package Nettle
Error: No matching Packages to list
WARNING: An exception occured while building binary dependencies.
You may have to take manual steps to complete the installation, see the error message below.
To reattempt the installation, run Pkg.fixup("Nettle").

 in build at pkg.jl:272
ERROR: failed process: Process(`yum list nettle`, ProcessExited(1)) [1]
 in error at error.jl:22
 in pipeline_error at process.jl:447
 in readbytes at process.jl:401
 in readall at process.jl:408
 in package_available at /home/kmsquire/.julia/BinDeps/src/dependencies.jl:105
 in can_provide at /home/kmsquire/.julia/BinDeps/src/dependencies.jl:406
 in _find_library at /home/kmsquire/.julia/BinDeps/src/dependencies.jl:330
 in satisfy! at /home/kmsquire/.julia/BinDeps/src/dependencies.jl:421 (repeats 2 times)
 in anonymous at /home/kmsquire/.julia/BinDeps/src/dependencies.jl:449
 in include at boot.jl:238
at /home/kmsquire/.julia/Nettle/deps/build.jl:37

There's also the issue that on some systems (such as shared clusters), yum (or something) might be installed, but users won't have root access.

Is there more documentation anywhere?

(I wanted to wrap some existing C routines for multidimensional integration, but Pkg distribution for something like this seems a lot harder than I would like. Although I guess part of the problem is that we can't depend on Mac or Windows users even having a compiler, it would be nice to be able to depend on something like cmake being present to portably build shared libraries.)

Is there a way to make the Autotools provider run autogen.sh before running configure? I'm trying to wrap a library that builds this way and having some trouble.

This may seem a naive question but how does one go about testing a build.jl file without committing a potentially incorrect version into the master branch on the public repository.

Here't the situation for me. For the Metis package I realized that the simplest installation on Debian-based systems is using

libmetis = library_dependency("libmetis", aliases=["libmetis5"])
Provides(AptGet, "libmetis5", libmetis)

So far so good. However, I should work out alternatives for downloading the sources and building from scratch - and for Yum, Homebrew, WinRPM, ...

If I want to test

provides{Sources, ...)

I need to install without using the AptGet provider. So how does one go about removing a package so that it really is removed and not just taken off the Required list? And what is the best way to install from scratch so that the modified build.jl file is executed? Should I use Pkg.clone?

Finally, the Metis library uses cmake instead of autotools for configuration. Has there been any thought about creating a Cmake provider similar to the Autotools provider?

julia> Pkg.fixup()
INFO: Running build script for package Cairo
WARNING: contains(collection, item) is deprecated, use in(item, collection) instead
 in contains at reduce.jl:238
WARNING: An exception occured while building binary dependencies.
You may have to take manual steps to complete the installation, see the error message below.
To reattempt the installation, run Pkg.fixup("Cairo").

 in build at pkg.jl:390
ERROR: no method package_available(Yum,)
 in can_provide at /usr/local/julia/julia-packages/BinDeps/src/dependencies.jl:387
 in _find_library at /usr/local/julia/julia-packages/BinDeps/src/dependencies.jl:311
 in satisfy! at /usr/local/julia/julia-packages/BinDeps/src/dependencies.jl:402 (repeats 2 times)
 in anonymous at /usr/local/julia/julia-packages/BinDeps/src/dependencies.jl:430
 in include at boot.jl:238
at /usr/local/julia/julia-packages/Cairo/deps/build.jl:134

This is using

julia> versioninfo()
Julia Version 0.2.0-prerelease+3754
Commit 349c336* 2013-09-17 04:57:44 UTC
Platform Info:
  System: Linux (x86_64-redhat-linux)
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm

Fixed by reverting to 0.2.4.

Can we pass some extra parameters to curl so that it can retry downloads after disconnects?

MESSAGE: Changing Directory to /Users/viral/.julia/Cairo/deps/builds/fontconfig-2.10.2
MESSAGE: Changing Directory to /Users/viral/.julia/Cairo/deps/builds/fontconfig-2.10.2
MESSAGE: Changing Directory to /Users/viral/.julia/Cairo/deps/builds/fontconfig-2.10.2
MESSAGE: Attempting to Create directory /Users/viral/.julia/Cairo/deps/downloads
MESSAGE: Directory /Users/viral/.julia/Cairo/deps/downloads already created
MESSAGE: Downloading file http://www.cairographics.org/releases/cairo-1.12.8.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0Bus error: 10
 87 40.1M   87 35.2M    0     0  61392      0  0:11:25  0:10:02  0:01:23 71599
curl: (18) transfer closed with 5118218 bytes remaining to read

In case of incomplete downloads, BinDeps should remove the partial download. Running the buildscript gives the following error:

julia> Pkg.runbuildscript("Cairo")
MESSAGE: Running build script for package Cairo
/Users/viral/.julia/Cairo/deps
MESSAGE: There are multiple options available for installing this dependency:
- skip: Skip Installation - Binaries must be installed manually
- brew: Install depdendency using brew
- source: Install depdendency from source
Plese select desired method: source
MESSAGE: Changing Directory to /Users/viral/.julia/Cairo/deps
<cut>

MESSAGE: Attempting to Create directory /Users/viral/.julia/Cairo/deps/downloads
MESSAGE: Directory /Users/viral/.julia/Cairo/deps/downloads already created
MESSAGE: Attempting to Create directory /Users/viral/.julia/Cairo/deps/downloads
MESSAGE: Directory /Users/viral/.julia/Cairo/deps/downloads already created
MESSAGE: Downloading file http://www.cairographics.org/releases/cairo-1.12.8.tar.xz
MESSAGE: Done downloading file http://www.cairographics.org/releases/cairo-1.12.8.tar.xz
MESSAGE: Attempting to Create directory /Users/viral/.julia/Cairo/deps/src
MESSAGE: Directory /Users/viral/.julia/Cairo/deps/src already created
MESSAGE: Attempting to Create directory /Users/viral/.julia/Cairo/deps/src/cairo-1.12.8
ERROR: in spawn: new not defined
 in spawn at process.jl:240
 in run at process.jl:377
 in run at /Users/viral/.julia/BinDeps/src/BinDeps.jl:359
 in run at /Users/viral/.julia/BinDeps/src/BinDeps.jl:376
 in run at /Users/viral/.julia/BinDeps/src/BinDeps.jl:376
 in run at /Users/viral/.julia/BinDeps/src/BinDeps.jl:376
 in run at /Users/viral/.julia/BinDeps/src/BinDeps.jl:147
 in run at /Users/viral/.julia/BinDeps/src/BinDeps.jl:376
 in include_from_node1 at loading.jl:76
 in anonymous at no file:206
 in cd at file.jl:26
 in runbuildscript at pkg.jl:203
at /Users/viral/.julia/Cairo/deps/build.jl:79

julia> 

From JuliaLang/julia#3761

During a Pkg.add("Winston"):

ERROR: no method joinpath(ASCIIString,Dict{Any,Any})
 in generate_steps at /Users/sabae/julia_packaging_home/BinDeps/src/dependencies.jl:267
 in satisfy! at /Users/sabae/julia_packaging_home/BinDeps/src/dependencies.jl:399
 in anonymous at /Users/sabae/julia_packaging_home/BinDeps/src/dependencies.jl:413
 in include_from_node1 at loading.jl:95
 in anonymous at no file:262
 in cd at file.jl:25
 in cd at pkg/dir.jl:28
 in build at pkg.jl:259
 in __fixup at pkg.jl:311
 in _fixup at pkg.jl:338
 in _fixup#g153 at no file
 in _fixup#g152 at no file
 in _fixup#g151 at no file
 in _resolve at pkg.jl:249
 in _resolve at no file
 in anonymous at no file:33
 in cd at file.jl:25
 in cd at pkg/dir.jl:28
 in edit at pkg.jl:23
 in add at pkg.jl:20
at /Users/sabae/julia_packaging_home/Cairo/deps/build.jl:115

Happened just after a successful install of libpng, it printed this out, then errored out:

Array((DependencyProvider,Dict{Symbol,Any}),(4,)) [(AptGet("libpixman-1-0"),Dict{Symbol,Any}()),(RemoteBinaries(URI(http://julialang.googlecode.com/files/Cairo.tar.
gz)),[:os=>:Windows]),(RemoteBinaries(URI(http://julialang.googlecode.com/files/OSX.tar.gz)),[:os=>:Darwin]),(Autotools(nothing,{:libtarget=>"pixman/libpixman-1.la"
,:installed_libname=>"libpixman-1.0.dylib"}),Dict{Symbol,Any}())]

This is on the latest published BinDeps, on julia version:

julia> versioninfo()
Julia Version 0.2.0-prerelease+3332
Commit 35153e8* 2013-08-19 22:48:27 UTC
Platform Info:
  System: Darwin (x86_64-apple-darwin12.4.0)
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY)
  LAPACK: libopenblas
  LIBM: libopenlibm

URI objects should allow (and strongly encourage) specifying a sha1 hash that is verified when the associated file is downloaded.

Cairo's build script uses MakeTargets, but it's not exported.

It is strange to get errors like ERROR: RPMmd package not installed, please run Pkg.add("RPMmd") when we have a package manager with dependency resolution. Short of merging, I guess there would need to be platform-specific dependency resolution, which seems unlikely.

Loading packages like Cairo is now significantly slower than it used to be, due to BinDeps.load_dependencies. This does a lot of work, including running deps/build.jl again. That script should only run once, and BinDeps should only be needed for installing, not on every use. Perhaps the library locations can be cached somewhere.

When a package needs to be installed, BinDeps calls the package manager using sudo. This means that when installing Winston, I was suddenly asked for my password without any explanation. I found out later that it was attempting to call yum to install gettext so that Cairo.jl could be built. That's not a good practice at all.

I think BinDeps should explain what package is missing to install what Julia package, and print the exact command that is being run via sudo.

A possibly better improvement both for you and for users would be to use PackageKit, which supports most distributions and would allow you to get rid of package manager specific code. PackageKit would take care of showing a dialog asking for password via PolicyKit, which is much preferred nowadays instead of plain sudo.

Great package anyway!

I'm not sure this is BinDeps fault, but i'm getting the following error:

MESSAGE: Attempting to Create directory /Users/nolta/.julia/Cairo/deps/downloads
MESSAGE: Directory /Users/nolta/.julia/Cairo/deps/downloads already created
MESSAGE: Downloading file http://www.cairographics.org/releases/cairo-1.12.8.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 40.1M  100 40.1M    0     0   687k      0  0:00:59  0:00:59 --:--:--  826k
MESSAGE: Done downloading file http://www.cairographics.org/releases/cairo-1.12.8.tar.xz
MESSAGE: Attempting to Create directory /Users/nolta/.julia/Cairo/deps/src
MESSAGE: Directory /Users/nolta/.julia/Cairo/deps/src already created
MESSAGE: Attempting to Create directory /Users/nolta/.julia/Cairo/deps/src/cairo-1.12.8
x cairo-1.12.8/
x cairo-1.12.8/COPYING
x cairo-1.12.8/ChangeLog.pre-1.0MESSAGE: Attempting to Create directory /Users/nolta/.julia/Cairo/deps/builds/cairo-1.12.8
/Users/nolta/.julia/Cairo/deps/builds/cairo-1.12.8
test
MESSAGE: Changing Directory to /Users/nolta/.julia/Cairo/deps/builds/cairo-1.12.8
/Users/nolta/.julia/Cairo/deps/src/cairo-1.12.8
MESSAGE: Changing Directory to /Users/nolta/.julia/Cairo/deps/builds/cairo-1.12.8
execvp(): No such file or directory

x cairo-1.12.8/config.h.in
x cairo-1.12.8/KNOWN_ISSUES
x cairo-1.12.8/build/
... 
x cairo-1.12.8/perf/micro/long-dashed-lines.c
x cairo-1.12.8/perf/micro/a1-line.c
x cairo-1.12.8/perf/micro/mosaic.hcould not start process Process(`/Users/nolta/.julia/Cairo/deps/src/cairo-1.12.8/configure LDFLAGS=-L/Users/nolta/.julia/Cairo/deps/usr/lib 'CPPFLAGS=-I/Users/nolta/.julia/Cairo/deps/usr/include -D_SSIZE_T_DEFINED=1' --without-x --disable-xlib --disable-xcb --enable-quartz --enable-quartz-font --enable-quartz-image --disable-gl --prefix=/Users/nolta/.julia/Cairo/deps/usr`, ProcessExited(-1))
 in error at error.jl:22
 in success at process.jl:424
 in wait_success at process.jl:560
 in run at process.jl:418
 in run at /Users/nolta/.julia/BinDeps/src/BinDeps.jl:416
 in run at /Users/nolta/.julia/BinDeps/src/BinDeps.jl:390
 in run at /Users/nolta/.julia/BinDeps/src/BinDeps.jl:416 (repeats 4 times)
 in run at /Users/nolta/.julia/BinDeps/src/BinDeps.jl:185
 in run at /Users/nolta/.julia/BinDeps/src/BinDeps.jl:416
 in build at none:80
 in evalfile at loading.jl:145
 in anonymous at no file:249
 in cd at file.jl:25
 in runbuildscript at pkg.jl:246
 in _resolve at pkg.jl:363
 in anonymous at no file:163
 in cd at file.jl:25
 in cd_pkgdir at pkg.jl:42
 in add at pkg.jl:143
 in add at pkg.jl:175

I was helping a user with a BinDeps install issue, and it turned out that autotools had installed the libraries into deps/usr/lib64. Can we add this to the search path?

As @carlobaldassi mentioned, most binaries for windows are pre-packaged and shouldn't be expected to unpack the libraries into usr/lib. There should be a simple syntax to specify in which directory the .dll's should be found. This is pretty easy to implement by overriding libdir, but the right syntax isn't clear.

In Bash, Julia always starts now assuming that I have 25 rows and 80 columns. This wasn't always the case, although I'm not sure yet when the change happened.

tty_rows() and tty_cols() determine rows and columns by reading the LINES and COLUMNS environment variables. However, these variables are shell variables in bash, and are not set as environment variables by default. (See: http://mywiki.wooledge.org/BashFAQ/091)

Related: #4513

BinDeps immediately dies for me now:

julia> using BinDeps
ERROR: syntax: invalid assignment location
 in include at boot.jl:238
 in include_from_node1 at loading.jl:96
 in reload_path at loading.jl:121
 in require at loading.jl:50
at /Users/johnmyleswhite/.julia/BinDeps/src/BinDeps.jl:289

Instead of relying on the name of .so files, which often vary across distributions, pkg-config could be used, since it has been designed precisely to avoid portability issues. Instead of a library .so name and a package name, you have one identifier that can be used to find the path to the .so file, and to install the package providing the corresponding library if missing.

RPM-based distributions already support installing a package using the construct pkgconfig(lib). for example

pkcon what-provides "pkgconfig(cairo)"

Should work for all RPM distributions (at least). But you can also use:

yum provides "pkgconfig(cairo)"

So I think it could be useful to make package developer's life easier to also check whether pkgconfig can be used when a library could not be found. This would help reduce the occurrence of bugs like JuliaGraphics/Cairo.jl#35 (comment)

See http://stick.gk2.sk/2010/10/why-is-pkg-config-the-best-thing-since-sliced-bread/ for more details.

The README lists DirectoryRule as public, but it not exported in BinDeps.jl

I was momentarily perplexed when bindeps asked for my password (to sudo apt-get tcl) ... this is actually great, but it would be nice to give a short explanation first!

In HttpParser.jl, the downloaded zip file is internally organized as usr/lib/*.dll. If this folder doesn't exist, this works fine. If it does already exist, and is empty, I get the "Provider Binaries failed to satisfy..." error. The last thing it says before giving up is

INFO: Directory ...\deps\usr already created

I now have a working GLPK Windows installer in an experimental branch of GLPK.jl:

https://github.com/carlobaldassi/GLPK.jl/blob/309ab10f566239f77acedb3d179b518ec741b14c/deps/build.jl

However, I had to somehow force BinDeps to accept BuildProcess as a provider on Windows:

@windows_only push!(BinDeps.defaults, BuildProcess)

@BinDeps.install

@windows_only pop!(BinDeps.defaults)

The issue is that the compiled binaries come in a peculiar directory structure, so I have to manipulate them to install the library under usr/lib, and I couldn't find a way to do this with a Binary provider.
Is this acceptable (i.e. could something go wrong with the above solution)? Is there a better way to do this?

This would be useful if e.g., one is unavailable or goes away. Looking at the source, I didn't see how this was possible right now, but if it is, then all it needs is documentation.

It would be nice to have some extra scaffolding around our integration with brew. I'm making this issue to track discussion and such, I'll be happy to implement it myself once I get the OK from you all.

• We should check that brew is available. If it is, we could then define functions like add_brew_option() or something instead of directly push!()'ing onto the installation options. This would be a much smoother failure mode than throwing execvp() errors.
• We should use $(brew --prefix) instead of /usr/local/ pretty much everywhere, but we should cache this value somewhere. I was thinking we could just define a brew_prefix inside BinDeps.jl, but it should really only be run if brew is available, so I wanted to tackle the above point first.

Possibly more, can't remember them right now though.....

julia> Pkg2.update()
MESSAGE: Updating METADATA...
Enter passphrase for key '/home/tim/.ssh/id_rsa': 
MESSAGE: Updating ImageView...
MESSAGE: Updating HDF5...
MESSAGE: Updating BinDeps...
MESSAGE: Updating Grid...
MESSAGE: Updating Cairo...
MESSAGE: Updating MAT...
MESSAGE: Updating Tk...
MESSAGE: Computing changes...
ERROR: URIParser has no version compatible with fixed requirements
 in anonymous at no file:99
 in cd at file.jl:25
 in cd at pkg2/dir.jl:28
 in resolve at pkg2.jl:87
 in anonymous at no file:84
 in cd at file.jl:25
 in cd at pkg2/dir.jl:28
 in update at pkg2.jl:48

I manually added it to .julia via a git clone, and that fixed this problem.

URIParser should also be listed among the requires of BinDeps.

At least 2 packages (GLPK and Cubature) call unpack_cmd directly, but with 2-arguments (which I assume worked at one point). Is it better to provide a version in BinUtils which accomodates this (splitting the extensions directly), or would it be better to file issues with those packages to use a different mechanism?

cf. jump-dev/GLPK.jl#5

It would be nice if packages ship with a default ext.jl file which just worked if the user already had the dependencies. The hinderance to this appears to be the convoluted way in which the ext.jl file is generated: it uses a macro to do the runtime dlopen check.
https://github.com/JuliaLang/BinDeps.jl/blob/master/src/dependencies.jl#L477

Instead, I propose the following template for ext.jl. ext_paths.jl would be auto-generated and would return the set of paths that BinDeps wants to search:

ext_paths = isfile("ext_paths.jl") ? include("ext_paths.jl") : String[]

checked_lib(path::String) = checked_lib([path])
function checked_lib{T}(path::Vector{T})
  lib = find_library(path, ext_paths)
  lib != "" || error("Unable to load $path\n\nPlease re-run Pkg.build(package), and restart Julia.")
  lib
end
_jl_libpangocairo = checked_lib("libpangocairo-1.0")
_jl_libcairo = checked_lib("libcairo")
_jl_libgobject = checked_lib("libgobject-2.0")
_jl_libpango = checked_lib("libpango-1.0")
#some_lib = checked_lib(["name1", "name2"])

This still assumes that the runtime name/location of the file is mostly constant, but it also allows some runtime determination and checking.

As noted in JuliaCrypto/Nettle.jl#7, on 64-bit CentOS (and presumably RedHat) linux systems autotools installs 64-bit libraries in $prefix/lib64 by default (and presumably 32-bit libraries in $prefix/lib, since that's how the rest of the system works). BinDeps currently only looks in $prefix/lib.

The current solution for Nettle is to override lib64 with lib, which could be done in BinDeps. The downside to this is if, by chance, a user logs into (and wants to run julia on) either a 32-bit or 64-bit system from the same account (such as on a cluster with both types of system). Seems unlikely, but might happen--outside of the US, 32-bit systems are still the norm, I think.

Just as an aside, Debian-based systems generally do the opposite: they use lib for 64-bit files, ad lib32 for 32-bit files on the same system.

but it should

julia> using Winston
Warning: New definition 
    |(SynchronousStepCollection,Any) at /home/kmsquire/.julia/v0.2/BinDeps/src/BinDeps.jl:283
is ambiguous with: 
    |(Any,NAtype) at /home/kmsquire/.julia/v0.2/DataArrays/src/operators.jl:502.
To fix, define 
    |(SynchronousStepCollection,NAtype)
before the new definition.
Warning: New definition 
    |(Any,SynchronousStepCollection) at /home/kmsquire/.julia/v0.2/BinDeps/src/BinDeps.jl:286
is ambiguous with: 
    |(NAtype,Any) at /home/kmsquire/.julia/v0.2/DataArrays/src/operators.jl:502.
To fix, define 
    |(NAtype,SynchronousStepCollection)
before the new definition.

(see also JuliaStats/DataArrays.jl#17)

I run into errors when installing Winston because unxz is not by default installed. Would it be possible to use tar's J option (e.g. tar xJv $file on line 57) to extract the xz archive directly? (I tried to do this, but kept on getting weird errors, so I just caved and installed unxz directly)

I tried to change the BinDeps.find_library to do this, but it hangs. Given DL_LOAD_PATH, should the packages just do their own push!(DL_LOAD_PATH...) and we can get rid of find_library?

    function find_library(pkg,libname,files)
        push!(DL_LOAD_PATH, joinpath(Pkg.dir(),pkg,"deps","usr","lib"))
    dl = C_NULL
        for filename in files
            dl = dlopen_e(filename)
            if dl != C_NULL
                return true
            end
        end

    return false
    end

Cc: @vtjnash

I have problems getting Winston or Gadfly working on both latest Mac OS X and Ubuntu 13.04. In both cases there seems to be an issue related to BinDeps. I have tried removing .julia directory before running:

Pkg.add("Winston")

At the end I get the error message:

MESSAGE: Running build script for package Cairo
ERROR: in module path: BinDeps not defined
 in include_from_node1 at loading.jl:76
 in anonymous at no file:241
 in cd at file.jl:26
 in runbuildscript at pkg.jl:238
 in _resolve at pkg.jl:314
 in anonymous at no file:155
 in cd at file.jl:26
 in cd_pkgdir at pkg.jl:34
 in add at pkg.jl:135
 in add at pkg.jl:167
at /home/ubuntu/.julia/Cairo/deps/build.jl:1

The only plotting package I have managed to install is Gaston.

A package of mine (WCSLIB) breaks if compiled with parallel make. Is there anyway to disable this?

Not exactly sure if this is purely a BinDeps issue, but here is what happened
(Windows version 0.2, Commit e5095c9a7d)

julia> Pkg.add("Images")
MESSAGE: Installing BinDeps v0.0.1
Cloning into 'BinDeps'...
...
MESSAGE: Running build script for package Cairo
C:\j.julia\Cairo\deps
ERROR: in anonymous: MakeTargets not defined

and now I'm not able to uninstall what managed to be installed in first place too

julia> Pkg.add("Cairo")
MESSAGE: Installing BinDeps v0.0.1
ERROR: Path BinDeps already exists! Please remove to allow installation.

julia> Pkg.rm("BinDeps")
ERROR: Package not required: BinDeps

julia> Pkg.rm("Images")
ERROR: Package not required: Images

brew accepts URLs to provide formulas. This mostly works as-is with BinDeps but I noticed that there are some places that make assumptions that the string provided is the name of the formula, e.g., the code that interacts with installed_homebrew_packages towards the end of BinDeps.jl.

The tcl-tk formula (see JuliaGraphics/Tk.jl#16) is not part of the default library, but part of the homebrew/dupes tap:
https://github.com/Homebrew/homebrew-dupes/blob/master/tcl-tk.rb

I guess the options would be:

• add functionality to install new taps: this could be a lot of effort for something that only needs to be done once. It also could be a potential security hole.
• maintain a custom julia tap: again, a lot of effort to keep up to date.
• post a message, requesting that the user brew tap homebrew/dupes manually.

INFO: Attempting to Create directory C:\Users\ihn\AppData\Roaming\Julia\packages
\ZMQ\deps\usr
WARNING: An exception occured while building binary dependencies.
You may have to take manual steps to complete the installation, see the error me
ssage below.
To reattempt the installation, run Pkg.fixup("ZMQ").

 in build at pkg.jl:386

ERROR: could not start process `7z x 'C:\Users\ihn\AppData\Roaming\Julia\package
s\ZMQ\deps\downloads\libzmq-3.3.tar.gz' -y -so`: no such file or directory (ENOE
NT)
 in test_success at process.jl:431
 in success at process.jl:439
 in all at reduce.jl:221
 in success at process.jl:442

at C:\Users\ihn\AppData\Roaming\Julia\packages\ZMQ\deps\build.jl:18

This is on windows with ce3a77 binary, and Pkg.update()'d to include JuliaInterop/ZMQ.jl@68a67ea5. I tried to follow it through, and I think it is running:

julia> run(`7z x $file -y -so`|>`7z x -si -y -ttar -o$directory`)

But this works fine when I set the vars and do it manually... @loladiro @staticfloat any ideas?

This issue is being filed by a script, but if you reply, I will see it.

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their test (if available) on both the stable version of Julia (0.2) and the nightly build of the unstable version (0.3).

The results of this script are used to generate a package listing enhanced with testing results.

The status of this package, BinDeps, on...

• Julia 0.2 is 'No tests, but package loads.'
• Julia 0.3 is 'No tests, but package loads.'

'No tests, but package loads.' can be due to their being no tests (you should write some if you can!) but can also be due to PackageEvaluator not being able to find your tests. Consider adding a test/runtests.jl file.

'Package doesn't load.' is the worst-case scenario. Sometimes this arises because your package doesn't have BinDeps support, or needs something that can't be installed with BinDeps. If this is the case for your package, please file an issue and an exception can be made so your package will not be tested.

This automatically filed issue is a one-off message. Starting soon, issues will only be filed when the testing status of your package changes in a negative direction (gets worse). If you'd like to opt-out of these status-change messages, reply to this message.

On linux, it is quite likely that the cairo package and dependencies are available. On mac, these dependencies are bundled in the downloadable application - but the user is still prompted to build.

I suggest running the find_library() functions in ext.jl first in build.jl, and only presenting the compilation choices to the user if find_library() fails. Depending on the package system available, BinDeps can even look in standard places to find these libraries.

This would greatly reduce the barrier to getting graphics working in Julia.

Not sure whether this is a Julia bug or a BinDeps bug, but a recent pull of Julia gives this:

julia> using Cairo
ERROR: regex matching is only available for bytestrings; use bytestring(s) to convert
 in include_from_node1 at loading.jl:92
 in reload_path at loading.jl:117
 in require at loading.jl:48
at /usr/local/julia/julia-packages/Cairo/src/../deps/build.jl:222
at /usr/local/julia/julia-packages/Cairo/src/Cairo.jl:4

(Line 222 actually refers to BinDeps.)

Resetting head to just before the awesome @dcjones regex performance improvements avoids this problem, although I didn't isolate the issue any more specifically than that.

As @ViralBShah pointed out, it would be cool if BinDeps provided this functionality so that package maintainers could provide a list of mirrors for things they need.

Origional: JuliaGraphics/Cairo.jl#14

Probably dependent on: #2

I went to try changing my packages to cache dependencies (#63), and noticed that this isn't documented anywhere. CC: @ihnorton

ERROR: Directory /home/mlubin/.julia/Clp/deps/src/Clp-1.14 was not created successfully (Tried to run `tar xzf /home/mlubin/.julia/Clp/deps/downloads/Clp-1.14.8.tgz --directory=/home/mlubin/.julia/Clp/deps/src` )

Note it's looking for Clp-1.14 when the file name is Clp-1.14.8.tgz.
Looks like the issue is in splittarpath.

There should be a useful error message if we try to do a source install on OS X and developer tools aren't installed.

Many BinDeps-based packages are not usable anymore on master, they give ERROR: stack overflow when loaded. Examples include NLopt (JuliaOpt/NLopt.jl#8), Cbc (jump-dev/Clp.jl#2), GnuTLS, Cairo, and Nettle: https://groups.google.com/forum/#!topic/julia-users/8fYniXykJ9M. What's going on?

@StefanKarpinski