PkgUtils.jl: Tools for analyzing Julia Packages

PkgUtils.jl

This package contains tools for analyzing Julia packages.

For now, it provides tools to build a highly simplified package search engine that can be queried as a service:

Example

Build a simplified search engine service:

using PkgUtils
PkgUtils.runservice()

Run a search website:

cd .julia/PkgUtils
julia scripts/server.jl
open site/index.html

Download Details:

Author: johnmyleswhite
Source Code: https://github.com/johnmyleswhite/PkgUtils.jl 

#julia #utils #tool 

What is GEEK

Buddha Community

PkgUtils.jl: Tools for analyzing Julia Packages

PkgUtils.jl

This package contains tools for analyzing Julia packages.

For now, it provides tools to build a highly simplified package search engine that can be queried as a service:

Example

Build a simplified search engine service:

using PkgUtils
PkgUtils.runservice()

Run a search website:

cd .julia/PkgUtils
julia scripts/server.jl
open site/index.html

Download Details:

Author: johnmyleswhite
Source Code: https://github.com/johnmyleswhite/PkgUtils.jl 

#julia #utils #tool 

PkgDev.jl: Tools for Julia Package Developers

PkgDev

Overview

PkgDev provides tools for Julia package developers. The package is currently being rewritten for Julia 1.x and only for brave early adopters.

Usage

PkgDev.tag(package_name, version=nothing; registry=nothing, release_notes=nothing)

Tag a new release for package package_name. The package you want to tag must be deved in the current Julia environment. You pass the package name package_name as a String. The git commit that is the HEAD in the package folder will form the basis for the version to be tagged.

If you don't specify a version, then the version field in the Project.toml must have the format x.y.z-DEV, and the command will tag version x.y.z as the next release. Alternatively you can specify one of :major, :minor or :patch for the version parameter. In that case PkgDev.tag will increase that part of the version number by 1 and tag that version. Finally, you can also specify a full VersionNumber as the value for the version parameter, in which case that version will be tagged.

The only situation where you would specify a value for registry is when you want to register a new package for the first time in a registry that is not General. In all other situations, PkgDev.tag will automatically figure out in which registry your package is registered. When you do pass a value for registry, it should simply be the short name of a registry that is one of the registries your local system is connected with.

If you want to add custom release notes for TagBot, do so with the release_notes keyword.

PkgDev.tag runs through the following process when it tags a new version:

1. Create a new release branch called release-x.y.z.
2. Change the version field in Project.toml and commit that change on the release branch.
3. Change the version field in Project.toml to x.y.z+1-DEV and commit that change also to the release branch. 4a. For packages in the General registry: add a comment that triggers Registrator. 4b. For packages in other registries: Open a pull request against the registry that tags the first new commit on the release branch as a new version x.y.z.
4. Open a pull request against the package repository to merge the release branch into master.

If you have TagBot installed for your package with the branches: true setting, it will automatically merge the release-x.y.z branch into master once the pull request for the registry has been merged. If you use the package butler (desribed below) it auto-configures your repository for this workflow.

PkgDev.enable_pkgbutler(package_name; channel=:auto, template=:auto)

Enables the Julia Package Butler for package package_name. The package must be deved in the current Julia environment. The command will make various modifications to the files in the deved folder of the package. You then then need to commit these changes and push them to GitHub. The command will also add a deploy key to the GitHub repository of the package and show instructions on how to add two GitHub Actions secrets to the repository.

The channel argument can be :auto, :stable or :dev. There are two channels of updates: stable and dev. The dev channel will run the Julia Package Butler workflow every 5 minutes and it will use the master branch of the Julia Packge Butler engine, i.e. it will get new features more quickly. The stable branch runs the Julia Package Butler workflow every hour, and new features in the Julia Package Butler engine are only pushed out to the stable channel once they have been tested for a while on the dev channel. If you specify :auto as the argument, any existing channel choice you have previously made for the package will be retained, otherwise the package will be configure for the stable channel.

The template argument can be :auto, :default or :bach. Different templates will configure different aspects of your package. At this point everyone should use the :default template (or :auto template), everything else is considered experimental.

PkgDev.switch_pkgbutler_channel(package_name, channel)

Switch the Julia Package Butler channel for package package_name. The package you want to tag must be deved in the current Julia environment and the Julia Package Butler must already be enabled for the package. The channel argument can be :auto, :stable or :dev, see the documentation for PkgDev.enable_pkgbutler for an explanation of the different channels.

PkgDev.switch_pkgbutler_template(package_name, template)

Switch the Julia Package Butler template for package package_name. The package you want to tag must be deved in the current Julia environment and the Julia Package Butler must already be enabled for the package. The template argument can be :auto, :default or :bach.

PkgDev.format(package_name)

Format all the Julia source code files for the package with name package_name. The package you want to format must be deved in the current Julia environment. This function uses DocumentFormat.jl.

Download Details:

Author: JuliaLang
Source Code: https://github.com/JuliaLang/PkgDev.jl 
License: View license

#julia #tool #dev 

PackageEvaluator.jl: A tool To Evaluate The Quality Of Julia Packages

PackageEvaluator

The purpose of PackageEvaluator is to attempt to test every Julia package nightly, and to provide the information required to generate the Julia package listing.

This is currently done for Julia 0.6 and nightly, and the tests are run in Ubuntu 14.04 LTS ("Trusty Tahr") virtual machines managed with Vagrant. This allows users to debug why their tests are failing, and allows PackageEvaluator to be run almost anywhere.

The code itself, in particular scripts/setup.sh, is heavily commented, so check that out for more information.

"My package is failing tests!"

Possible reasons include:

• Your package is out of date. PackageEvaluator tests the last released version of your package, not master. Make sure you've tagged a version with your bug fixes included.
• You have a binary dependency that BinDeps can't handle.
  • If the binary dependency is a commerical package, or does not work on Ubuntu (e.g. OSX only), then the package should be excluded from testing. Please submit a pull request adding a line to src/constants.jl.
  • If the binary dependency is something that is not installable (or shouldn't be installed) through BinDeps, like a Python package or R package, then it should be added to the provisioning script. Please submit a pull request adding a line to scripts/setup.sh.
• You have a testing-only dependency that you haven't declared. Create (or check) your package's test/REQUIRE file.
• *Your package only works on Windows/OSX/one particular -nix. Your package might need to be excluded from testing. Please submit a pull request adding a line to src/constants.jl saying your package shouldn't be run.
• Your testing process relies on random numbers. Please make sure you set a seed or use appropriate tolerances if you rely on random numbers in your tests.
• Your package relies on X running. It may be possible to get your package working through the magic of xvfb. Please submit a pull request adding a line to src/constants.jl that specifies that your package needs to be run with xvfb active.
• Your package's tests or installation take too long. There is a time limit of 30 minutes for installation, and a seperate 10 minute time limit for testing. You can either reduce your testing time, or exclude your package from testing.
• Your package requires too much memory. The VMs only have 2 GB of RAM. You can either reduce your test memory usage, or exclude your package from testing.
• Your tests aren't being found / wrong test file is being run. Your package needs a test/runtests.jl file. PackageEvaluator will execute it with Pkg.test.
• Something else. You'll probably need to check manually on the testing VM. See next section.

(Licenses are searched for in the files listed in src/constants.jl. The goal is to support a variety of licenses. If your license isn't detected, please file a pull request with detection logic.)

Using Vagrant and PackageEvaluator

• Vagrant is a tool for creating and managing virtual machines.
• The configuration of the virtual machine, including the operating system to use, live in the Vagrantfile.
• When the virtual machine(s) are launched with vagrant up, a provisioning script called setup.sh is run.
• This script takes two arguments. The first is the version of Julia to use (0.6 or 0.7)
• The second determines the mode to operate in:
  • setup: set up the machine with Julia and the same dependencies that are used for a full PackageEvaluator run, but do not do any testing.
  • all: do setup and evaluate all the packages.
  • AF, GO, PZ: evaluate only packages with names beginning with those letters.
• Each combination of settings corresponds to a named virtual machine - see scripts/Vagrantfile for the list of the VMs.

Download Details:

Author: JuliaCI
Source Code: https://github.com/JuliaCI/PackageEvaluator.jl 
License: MIT license

#julia #tool 

Qlab.jl: Generic Lab tools in Julia

Qlab.jl

Data manipulation and analysis tools tailored for quantum computing experiments in conjunction with Auspex. Currently working with Julia v1.0.

Installation

(v1.3) pkg> add https://github.com/BBN-Q/Qlab.jl

The code base also uses some system tools and python libraries for building libraries and plotting data with PyPlot.jl. You'll want to make sure your system has these.

In CentOS:

yum -y install epel-release
yum install gcc gcc-c++ make bzip2 hdf5 libaec libgfortran libquadmath

In Ubuntu/Debian:

apt-get install gcc g++ gcc-7-base make libaec0 libgfortran4 libhdf5-100 libquadmath0 libsz2

Python

You'll need a working version of PyPlot. In some cases the package manager has trouble getting this right on all systems/OSs. If you run into issues, we recommend using Conda.jl manually:

using Pkg
Pkg.add("PyCall")
Pkg.add("Conda")
ENV["PYTHON"] = ""
Pkg.build("PyCall")
using Conda
Conda.add("matplotlib")
Conda.add("seaborn")
Pkg.add("PyPlot")

In most cases, Julia should take care of this for you.

Other dependancies

Qlab.jl depends on several other Julia packages that have biniary dependencies. These should mostly be taken care of by the package manager. One important exception is HDF5 and its libhdf5 dependancy. This library manages the handling of HDF5 files and is currently maintained for backwards compatibility. The version of libhdf5 which produced any data files you want to analyze must match the library version used to create the files. You may need to add the path the the right version of libhdf5 to the Libdl path in Julia and rebuild HDF5:

push!(Libdl.DL_LOAD_PATH, "/opt/local/lib")
Pkg.build("HDF5")

where /opt/local/lib is the path to the correct version of libhdf5. See the documentation from HDF5.jl for more details. Currently only version of hdf5 1.8.2 - 1.8.17 are supported. If you're not planning to use HDF5 files, you shouldn't have to worry about the library versions matching.

Copyright

Raytheon BBN Technologies.

Download Details:

Author: BBN-Q
Source Code: https://github.com/BBN-Q/Qlab.jl 
License: View license

#julia #tool 

Lint.jl: A Lint tool for Julia Code

Lint.jl

Lint.jl is a tool that uses static analysis to assist in the development process by detecting common bugs and potential issues.

Installation

Lint.jl can be installed through the Julia package manager:

Pkg.add("Lint")

Usage

There are 3 functions you can use to lint your code.

• lintpkg("MyPackage") for linting an entire package
• lintfile("my_file.jl") for linting a file
• lintstr("my string") for linting a string

Documentation

Detailed documentation is available for:

• Latest Release
• Development

Download Details:

Author: Tonyhffong
Source Code: https://github.com/tonyhffong/Lint.jl 
License: View license

#julia #tool #code