GitLab

v3.0

See merge request !26

I think we're ready to merge, I'm happy with the state of the code and
the state of the docs. I'd like to majorly refactor before a 1.0.0
release, but this is just fine for now.

Replace rand 0.5 with rand_os 0.1

See merge request !27

redox_users only uses the OsRng struct which has been moved to the
rand_os crate.

Basically takes advantage of the configuration struct.
The tests still fail and I still don't know why.

For some reason that I cannot ascertain, two tests still fail. I have
examined values basically everywhere and cannot figure it out. User and
Group get Debug now though.

The tests still don't pass, but this is a big step. Solves #23.

AllUsers and AllGroups instances now take a configuration struct which
allows a little finer control over the behavior of the library. Docs
included with this commit.

Update rand crate to 0.5

See merge request !24

Use stages in CI

See merge request !23

Remove FromIter; Bump Version

See merge request !22

Gitlab CI

See merge request !21

Mggmuggins/shadowfile

This removes fs2 and linux file locking and simply runs the tests
without concurrency rather than actually fixing file locking to make
them work like they should.The value of working file locking on Linux is
debatable anyway.

I'll open an issue to track file locking with this repo, and maybe go
and do some work to get it implemented for Redox.

I used `cfg(not(target_os = "redox"))` for all the non-redox locking
behavior (including fs2), even though we only use it for tests. I'm
hoping that is alright.

This is just changing a bunch of function headers to use T: AsRef<str>
instead of String, and making things more consistent in general.

This is at a point where the implementation should work. The only way to
know for sure that it doesn't is to write more tests :/

I basically went through all the documentation and checked it to make
sure it was up to date with the implementations, and I added some crate
level notes.

Wrote a few more tests, made sure that doing dumb things would fail,
etc.

This is still very much a WIP. There are a number of things that I know
shouldn't work, and that I haven't written tests for yet. That'll be
coming at a later date. However, the current test suite passes and it
does mostly work.

The internal API is kinda messy. I mean,
`Option<(String, Option<Encoded>)>??!! Anyway, there's some
stuff that is really not pretty, and I would be happy for advice on how
to make it look a little nicer and be more maintainable..

Travis; Rustfmt; Update README

Readme; Rustify

Added config files for those two services. I'm not going to require
formatting via travis, but I thought I'd add everything so it won't do
major things to code we'd already written if somebody runs it.

@jackpot51, how difficult would it be to get travis for this repo?

Tests! Fix #15

Fix Up read/write so that they will work on linux.

Wrote big tests!
These are designed to be run on linux, in a regular cargo environment.
Do not edit things in `tests/`, they will break!

Just added some cargo metadata

Also added a few lines for getting ready to test. Another commit will
come soon with a few basic tests to make sure that everything is working
alright.