Release: v0.5.0

.gitignore

@@ -0,0 +1,9 @@
+# C extensions
+*.so
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+
+# Built files
+target/
+

CONTRIBUTING.md

@@ -0,0 +1,50 @@
+# Developer Guidelines
+
+Any contributions are welcome! Below is a brief description of the project structure.
+
+## Structure
+
+### `src/record.rs`
+This file contains the `Record` trait, which defines a set of functions that specific DMAP formats must implement.
+For example, `read_file(infile: &PathBuf) -> Result<Vec<Self>, DmapError>` is defined in the `Record` trait, and handles
+reading in records from a file at the specified path. This function is generic, in that it doesn't know what type of records
+(RAWACF, FITACF, etc.) are expected. Also, since it is a trait function, you can only use it through a struct which implements
+the trait. For example, the `FitacfRecord` struct defined in `src/formats/fitacf.rs` implements the `Record` trait, and so
+you can call `FitacfRecord::read_file(...)` to read a FITACF file, but you couldn't invoke `Record::read_file(...)`.
+
+### `src/types.rs`
+This file defines necessary structs and enums for encapsulating basic types (`i8`, `u32`, `String`, etc.) into
+objects like `DmapField`, `DmapScalar`, `DmapVec`, etc. that abstract over the supported underlying types.
+For instance, when reading scalar from a DMAP file, the underlying data type is inferred from the `type` field in the 
+scalar's metadata, so it can't be known beforehand. This requires some encapsulating type, `DmapScalar` in this case,
+which contains the metadata of the field and has a known size for the stack memory. 
+
+This file defines the `Fields` struct, which is used to hold the names and types of the required and optional
+scalar and vector fields for a type of DMAP record (RAWACF, FITACF, etc.).
+
+This file defines the `DmapType` trait and implements it for supported data types that can be in DMAP records, namely
+`u8`, `u16`, `u32`, `u64`, `i8`, `i16`, `i32`, `i64`, `f32`, `f64`, and `String`. The implementation of the trait for
+these types only means that other types, e.g. `i128`, cannot be stored in DMAP records.
+
+Lastly, functions for parsing scalars and vectors from a byte buffer are defined in this file.
+
+### `src/formats`
+This directory holds the files that define the DMAP record formats: IQDAT, RAWACF, FITACF, GRID, MAP, SND, and the generic DMAP.
+If you are defining a new DMAP format, you will need to make a new file in this directory following the structure of the
+existing files. Essentially, you define the scalar and vector fields, both required and optional, and the groups of vector
+fields which must have identical dimensions, then call a macro to autogenerate the struct code for you. 
+
+### `src/compression.rs`
+This file contains the automatic bz2 detection function. If more compression types are to be supported, this is where you would
+put them.
+
+### `src/io.rs`
+This file contains the function `bytes_to_file`, which handles writing a `Vec<u8>` to `AsRef<Path>`. If the path
+ends in `.bz2`, the function will compress first with bz2.
+
+### `tests`
+In `tests.rs`, integration tests for reading and writing all file types are present. Small example files
+are contained in `tests/test_files`.
+
+### `benches/io_benchmarking.rs`
+This file contains benchmarking functions for checking the performance of the basic read functions.

COPYING

@@ -0,0 +1,165 @@
+                   GNU LESSER GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+  This version of the GNU Lesser General Public License incorporates
+the terms and conditions of version 3 of the GNU General Public
+License, supplemented by the additional permissions listed below.
+
+  0. Additional Definitions.
+
+  As used herein, "this License" refers to version 3 of the GNU Lesser
+General Public License, and the "GNU GPL" refers to version 3 of the GNU
+General Public License.
+
+  "The Library" refers to a covered work governed by this License,
+other than an Application or a Combined Work as defined below.
+
+  An "Application" is any work that makes use of an interface provided
+by the Library, but which is not otherwise based on the Library.
+Defining a subclass of a class defined by the Library is deemed a mode
+of using an interface provided by the Library.
+
+  A "Combined Work" is a work produced by combining or linking an
+Application with the Library.  The particular version of the Library
+with which the Combined Work was made is also called the "Linked
+Version".
+
+  The "Minimal Corresponding Source" for a Combined Work means the
+Corresponding Source for the Combined Work, excluding any source code
+for portions of the Combined Work that, considered in isolation, are
+based on the Application, and not on the Linked Version.
+
+  The "Corresponding Application Code" for a Combined Work means the
+object code and/or source code for the Application, including any data
+and utility programs needed for reproducing the Combined Work from the
+Application, but excluding the System Libraries of the Combined Work.
+
+  1. Exception to Section 3 of the GNU GPL.
+
+  You may convey a covered work under sections 3 and 4 of this License
+without being bound by section 3 of the GNU GPL.
+
+  2. Conveying Modified Versions.
+
+  If you modify a copy of the Library, and, in your modifications, a
+facility refers to a function or data to be supplied by an Application
+that uses the facility (other than as an argument passed when the
+facility is invoked), then you may convey a copy of the modified
+version:
+
+   a) under this License, provided that you make a good faith effort to
+   ensure that, in the event an Application does not supply the
+   function or data, the facility still operates, and performs
+   whatever part of its purpose remains meaningful, or
+
+   b) under the GNU GPL, with none of the additional permissions of
+   this License applicable to that copy.
+
+  3. Object Code Incorporating Material from Library Header Files.
+
+  The object code form of an Application may incorporate material from
+a header file that is part of the Library.  You may convey such object
+code under terms of your choice, provided that, if the incorporated
+material is not limited to numerical parameters, data structure
+layouts and accessors, or small macros, inline functions and templates
+(ten or fewer lines in length), you do both of the following:
+
+   a) Give prominent notice with each copy of the object code that the
+   Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the object code with a copy of the GNU GPL and this license
+   document.
+
+  4. Combined Works.
+
+  You may convey a Combined Work under terms of your choice that,
+taken together, effectively do not restrict modification of the
+portions of the Library contained in the Combined Work and reverse
+engineering for debugging such modifications, if you also do each of
+the following:
+
+   a) Give prominent notice with each copy of the Combined Work that
+   the Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the Combined Work with a copy of the GNU GPL and this license
+   document.
+
+   c) For a Combined Work that displays copyright notices during
+   execution, include the copyright notice for the Library among
+   these notices, as well as a reference directing the user to the
+   copies of the GNU GPL and this license document.
+
+   d) Do one of the following:
+
+       0) Convey the Minimal Corresponding Source under the terms of this
+       License, and the Corresponding Application Code in a form
+       suitable for, and under terms that permit, the user to
+       recombine or relink the Application with a modified version of
+       the Linked Version to produce a modified Combined Work, in the
+       manner specified by section 6 of the GNU GPL for conveying
+       Corresponding Source.
+
+       1) Use a suitable shared library mechanism for linking with the
+       Library.  A suitable mechanism is one that (a) uses at run time
+       a copy of the Library already present on the user's computer
+       system, and (b) will operate properly with a modified version
+       of the Library that is interface-compatible with the Linked
+       Version.
+
+   e) Provide Installation Information, but only if you would otherwise
+   be required to provide such information under section 6 of the
+   GNU GPL, and only to the extent that such information is
+   necessary to install and execute a modified version of the
+   Combined Work produced by recombining or relinking the
+   Application with a modified version of the Linked Version. (If
+   you use option 4d0, the Installation Information must accompany
+   the Minimal Corresponding Source and Corresponding Application
+   Code. If you use option 4d1, you must provide the Installation
+   Information in the manner specified by section 6 of the GNU GPL
+   for conveying Corresponding Source.)
+
+  5. Combined Libraries.
+
+  You may place library facilities that are a work based on the
+Library side by side in a single library together with other library
+facilities that are not Applications and are not covered by this
+License, and convey such a combined library under terms of your
+choice, if you do both of the following:
+
+   a) Accompany the combined library with a copy of the same work based
+   on the Library, uncombined with any other library facilities,
+   conveyed under the terms of this License.
+
+   b) Give prominent notice with the combined library that part of it
+   is a work based on the Library, and explaining where to find the
+   accompanying uncombined form of the same work.
+
+  6. Revised Versions of the GNU Lesser General Public License.
+
+  The Free Software Foundation may publish revised and/or new versions
+of the GNU Lesser General Public License from time to time. Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.
+
+  Each version is given a distinguishing version number. If the
+Library as you received it specifies that a certain numbered version
+of the GNU Lesser General Public License "or any later version"
+applies to it, you have the option of following the terms and
+conditions either of that published version or of any later version
+published by the Free Software Foundation. If the Library as you
+received it does not specify a version number of the GNU Lesser
+General Public License, you may choose any version of the GNU Lesser
+General Public License ever published by the Free Software Foundation.
+
+  If the Library as you received it specifies that a proxy can decide
+whether future versions of the GNU Lesser General Public License shall
+apply, that proxy's public statement of acceptance of any version is
+permanent authorization for you to choose that version for the
+Library.

Cargo.toml

@@ -1,8 +1,14 @@
 [package]
-name = "dmap"
-version = "0.4.0"
+name = "darn-dmap"
+version = "0.5.0"
 edition = "2021"
 rust-version = "1.63.0"
+authors = ["Remington Rohel"]
+description = "SuperDARN DMAP file format I/O"
+repository = "https://github.com/SuperDARNCanada/dmap"
+license = "LGPL-3.0-or-later"
+keywords = ["SuperDARN", "dmap", "I/O"]
+categories = ["parser-implementations", "science"]
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 
@@ -13,8 +19,8 @@ name = "dmap"
 crate-type = ["cdylib", "rlib"]
 
 [dependencies]
-pyo3 = { version = "0.22.5", features = ["extension-module", "indexmap", "abi3-py38"] }
-numpy = "0.22.0"
+pyo3 = { version = "0.26.0", features = ["extension-module", "indexmap", "abi3-py38"] }
+numpy = "0.26.0"
 indexmap = "2.3.0"
 itertools = "0.13.0"
 rayon = "1.10.0"

README.md

@@ -1,49 +1,30 @@
-# Dmap
+A library for SuperDARN DMAP file I/O
+=====================================
 
-Rust tools for SuperDARN DMAP file format operations.
+[![github]](https://github.com/SuperDARNCanada/dmap) [![crates-io]](https://crates.io/crates/darn-dmap) [![docs-rs]](crate)
+
+[github]: https://img.shields.io/badge/github-8da0cb?style=for-the-badge&labelColor=555555&logo=github
+[crates-io]: https://img.shields.io/badge/crates.io-fc8d62?style=for-the-badge&labelColor=555555&logo=rust
+[docs-rs]: https://img.shields.io/badge/docs.rs-66c2a5?style=for-the-badge&labelColor=555555&logo=docs.rs
 
 This project exposes both Rust and Python APIs for handling DMAP I/O.
-I/O can be conducted either on byte buffers, or directly to/from files.
+I/O can be conducted either directly to/from files or byte buffers.
 
 The SuperDARN DMAP file formats are all supported (IQDAT, RAWACF, FITACF, GRID, MAP, and SND)
-as well as a generic DMAP format that is unaware of any required fields or types 
-(e.g. char, int32) for any fields.
+as well as a generic DMAP format that is unaware of any required fields or types (e.g. char, int32) for any fields.
 
-## Developer Guidelines
+## Installation
 
-### `src/record.rs`
-This file contains the `Record` trait, which defines a set of functions that specific DMAP formats must implement.
-For example, `read_file(infile: &PathBuf) -> Result<Vec<Self>, DmapError>` is defined in the `Record` trait, and handles
-reading in records from a file at the specified path. This function is generic, in that it doesn't know what type of records
-(RAWACF, FITACF, etc.) are expected. Also, since it is a trait function, you can only use it through a struct which implements
-the trait. For example, the `FitacfRecord` struct defined in `src/formats/fitacf.rs` implements the `Record` trait, and so
-you can call `FitacfRecord::read_file(...)` to read a FITACF file, but you couldn't invoke `Record::read_file(...)`.
+### Rust
+1. Add the crate to your dependencies in your `Cargo.toml` file
+2. Add `use dmap::*;` to your imports.
 
-### `src/types.rs`
-This file defines necessary structs and enums for encapsulating basic types (`i8`, `u32`, `String`, etc.) into
-objects like `DmapField`, `DmapScalar`, `DmapVec`, etc. that abstract over the supported underlying types.
-For instance, when reading scalar from a DMAP file, the underlying data type is inferred from the `type` field in the 
-scalar's metadata, so it can't be known beforehand. This requires some encapsulating type, `DmapScalar` in this case,
-which contains the metadata of the field and has a known size for the stack memory. 
+### Python
+This package is registered on PyPI as `darn-dmap`, you can install the package with your package manager.
 
-This file defines the `Fields` struct, which is used to hold the names and types of the required and optional
-scalar and vector fields for a type of DMAP record (RAWACF, FITACF, etc.).
-
-This file defines the `DmapType` trait and implements it for supported data types that can be in DMAP records, namely
-`u8`, `u16`, `u32`, `u64`, `i8`, `i16`, `i32`, `i64`, `f32`, `f64`, and `String`. The implementation of the trait for
-these types only means that other types, e.g. `i128`, cannot be stored in DMAP records.
-
-Lastly, functions for parsing scalars and vectors from a byte buffer are defined in this file.
-
-### `src/formats`
-This directory holds the files that define the DMAP record formats: IQDAT, RAWACF, FITACF, GRID, MAP, SND, and the generic DMAP.
-If you are defining a new DMAP format, you will need to make a new file in this directory following the structure of the
-existing files. Essentially, you define the scalar and vector fields, both required and optional, and the groups of vector
-fields which must have identical dimensions, then call a macro to autogenerate the struct code for you. 
-
-### `tests`
-In `tests.rs`, integration tests for reading and writing all file types are present. Small example files
-are contained in `tests/test_files`.
-
-### `benches/io_benchmarking.rs`
-This file contains benchmarking functions for checking the performance of the basic read functions.
+### From source
+If you want to build from source, you first need to have Rust installed on your machine. Then:
+1. Clone the repository: `git clone https://github.com/SuperDARNCanada/dmap`
+2. Run `cargo build` in the repository directory
+3. If wanting to install the Python API, create a virtual environment and source it, then install `maturin`
+4. In the project directory, run `maturin develop` to build and install the Python bindings. This will make a wheel file based on your operating system and architecture that you can install directly on any compatible machine.

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "maturin"
 
 [project]
 name = "darn-dmap"
-version = "0.4.0"
+version = "0.5.0"
 requires-python = ">=3.8"
 authors = [
     { name = "Remington Rohel" }
@@ -13,11 +13,25 @@ classifiers = [
     "Programming Language :: Python",
     "Programming Language :: Rust"
 ]
+description = "SuperDARN DMAP file format I/O"
+readme = "python/README.md"
 dependencies = ["numpy<3"]
+license = "LGPL-3.0-or-later"
+
+[project.urls]
+Repository = "https://github.com/SuperDARNCanada/dmap"
 
 [tool.maturin]
+python-source = "python"
+module-name = "dmap.dmap_rs"
 bindings = "pyo3"
 profile = "release"
 compatibility = "manylinux2014"
 auditwheel = "repair"
 strip = true
+
+[project.optional-dependencies]
+dev = [
+    "pytest",
+    "ruff",
+]