docker/go-units

Parse and print size and time units in human-readable format

Introduction

go-units is a library to transform human friendly measurements into machine friendly values.

Usage

See the docs in godoc for examples and documentation.

Copyright and license

Copyright © 2015 Docker, Inc.

go-units is licensed under the Apache License, Version 2.0. See LICENSE for the full text of the license.

go-units's Issues

RAMInBytes not parsing strings returned by BytesSize

Example:

units.RAMInBytes("32GiB")

This returns an error...

FromHumanSize accepts MiB but returns MB

One might expect that FromHumanSize("1MiB") would either

• return error
• return units.MiB (1024 * 1024 * 1024)

Currently it does not raise error and returns units.MB (1000 * 1000 * 1000)

Unify license

Licensing README under different license seems unnecessary. Why?
There is a good reason to use one license.

Could the whole package be (re-)licensed under Apache-2.0 please? Thanks.

`docker run -m 100MB` while `docker stats` show a limit of 104.9 MB

related to moby/moby#21765

In docker master, docker uses go-unit to traslate 100MB in to bytes: https://github.com/docker/docker/blob/master/runconfig/opts/parse.go#L163

As a result, 100MB input is dealed with use of RAMInBytes, it becomes 100MiB=104857600=104.9MB. I think this will confuse user.

And what confuses me is that does RAMInBytes have some special meanings?
People's 1MB in RAM means 1024_1024_1024 bytes=1MiB?

Inconsistent decimal places

go-units removes trailing zeros in its output. This makes the output in Docker's progress indicators not line up.

Current:

cba48ac2c991: Downloading    23 MB/37.18 MB
f19be92d17a1: Downloading  24.3 MB/64.6 MB

Better:

cba48ac2c991: Downloading  23.0 MB/37.18 MB
f19be92d17a1: Downloading  24.3 MB/64.60 MB

One decimal place should be enough when dealing with sizes:

cba48ac2c991: Downloading  23.0 MB/37.2 MB
f19be92d17a1: Downloading  24.3 MB/64.6 MB

HumanSizeWithPrecision uses scientific notation in some invalid cases

Let's keep it short, such a test will fail:

assertEquals(t, "1GB", HumanSizeWithPrecision(999.6*MB, 3))

With the following message:

Expected '1GB' but got '1e+03MB'

The case holds in the following scenarios:

• any 999.5 <= x < 1000 for any unit including bytes, kB, MB, GB, etc. (with precision 1, 2, or 3)
• any 99.5 <= x < 1000 for any unit including bytes, kB, MB, GB, etc. (with precision 1 or 2)
• any 9.5 <= x < 1000 for any unit including bytes, kB, MB, GB, etc. (with precision 1)

However, it works fine with precision 4 or higher.

v0.3.1 release 👼

We should tag the 0.3.1 release (and update vendoring in docker/docker)

/ping @calavera @thaJeztah @LK4D4

Release 0.5.0 (or 0.4.1)

Can we please merge #36 and release v0.4.1 (or v.0.5.0)?

Commits since v0.4.0 (at the moment this is just PR #40): v0.4.0...master

Tag 0.3.3

Hi there, thanks for the helpful lib! Could we get a tag v0.3.3 pushed to include the fix from #27?

Thanks!

Move to under moby org

As discussed with @thaJeztah, this repo needs to be move to under moby, i.e. become github.com/moby/go-units.

HumanSize strings cannot be round-tripped

If I do:

size, err := units.FromHumanSize(units.HumanSize(1024.0 * 1024.0 * 1024.0))

I will get as an error:

invalid size: '1.074GB'

Presumably, FromHumanSize should be able to parse the strings that HumanSize outputs. I believe that this is because FromHumanSize doesn't handle decimal points.

Please tag new release

Version bump is needed to fix FTBFS in engine-api. Thanks.