Skip to content

Commit

Permalink
null commit to make things work maybe?
Browse files Browse the repository at this point in the history
  • Loading branch information
redruin1 committed Nov 23, 2023
1 parent a3920e4 commit c15bd3c
Show file tree
Hide file tree
Showing 237 changed files with 22,693 additions and 12,087 deletions.
2 changes: 1 addition & 1 deletion .coveragerc
Original file line number Diff line number Diff line change
Expand Up @@ -2,4 +2,4 @@
[run]
omit = draftsman/env.py
branch = True
command_line = -m pytest test -vv -Werror
command_line = -m pytest test -Werror -vv
50 changes: 40 additions & 10 deletions TODO.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,43 @@
# TODO

### Redo validation (again)
Swapping to Pydantic was very illuminating in the benefits that it can provide:

* Ergonomic class definitions to define schemas (very nice)
* Being able to inject custom functions at any point of the validation process to massage inputs, discredit validation, and add new criteria (possibly on the fly!) This is probably going to be required by any further implementation going forward
* All of these validation functions are localized to the classes that use them, and everything is in one place; only a single method has to be called for any member modification.
* Validation backend is written in Rust for speed (tempting)

However, it is still not quite entirely perfect:

* RootModel syntax cannot be serialized if not in the correct model format (unacceptable, currently this is sidestepped but suboptimal)
* RootModel syntax is unwieldly; everything is accessed via it's `root` attribute and any methods that you would want to use on `root` have to be reimplemented in the parent class
* I HAVE to use RootModels if I want to be able to reliably validate these members (and ideally propagate their `is_valid` flags)
* Per instance validate assignment is not permitted (even though totally functional), meaning I have to use the model's backend which might be subject to change
* No in-built handling for warnings, which ideally would behave very similarly to errors as Pydantic currently implements them

Based on my search, I can't think of a validation library that has all of these features at once, implying that I would have to roll my own. I'm not really looking forward to this, and especially not to *testing* it, so if there is one out there please message me.

---

### Validation caching
Ideally, whether or not a entity or blueprint is considered valid can be retained as long as the entity does not change after validation. For example, if you validate a single entity, and then add that entity to a blueprint 1000 times, you only have to validate the attributes of the blueprint itself, since the entities are guaranteed to already be in a valid state. Ideally, each exportable object would have a `is_valid` attribute which would be set to false when an attribute is set, which can then be quickly checked in any parent
`validate()` function.

### Integrate with `mypy`

### Revamp the `add_x` data functions so that they support more features
* Inline sorting
* Support additional keyword arguments in line with the prototype documentation
* Perhaps there might be a way to redesign `env.py` such that it can use the data functions, encouraging code reuse

### More elegantly handle when a prototype has no valid members (like `LinkedBelt`)

### Change all internal attribute accesses to use `["element"]` and `.get("element", None)` instead so that functionality should remain constant when importing dicts when `validate="none"`

### Add keyword arguments to all draftsman entities and blueprintables
So the user can quickly determine what keys are allowed without having to consult the docs firsthand, or create an instance of it and check it's members

### Add as many of the example programs to the test suite as possible
To help ensure that they're behaving correctly over any API changes, so they stay up-to-date

Expand All @@ -19,10 +57,6 @@ General constraints on parameters and inputs; what you can deconstruct, what you
### Write `__repr__` function for everything
For most of the commonly-used things this is already the case, but would be nice if every Draftsman object had a nice, user-readable formatted output.

---
### Unify entity validation into one monolithic thing
Currently `Entity` and `Blueprintable` have two slightly different methods of converting their Python object representation to their output JSON dict/string format. Ideally this would be one single method (and thus one single point of failure to maintain).

---
### Write `dump_format` (and test_cases)
Do this not only for all the blueprintable types, but also each entity. In addition, include this output at the header of each documentation file, so people finally have a concrete reference for the actual blueprint string format
Expand Down Expand Up @@ -83,11 +117,7 @@ Documentation is currently written in [reStructuredText](https://docutils.source
Currently all the data being extracted from the Factorio load process is all "hard-coded"; you have to manually edit `env.py` in order to change what it extracts. This is alright for the maintainers of Draftsman as we can simply edit it if we need more/less information from `data.raw`, but what if the user wants some data from Factorio that Draftsman doesn't bother extracting? In this case Draftsman would benefit from a generic editable interface where people can configure and modify exactly the information they want from the game for whatever their purposes are.

---
### Maybe integrate defaults for more succinct blueprint strings?
A bootleg version of this currently exists already, where null entries are removed, but there should also be some kind of control for the "verbosity" of the output blueprint dict/string

---
### In the same vein as above, also perhaps an option for blueprint canonicalization
### Perhaps add an option for blueprint canonicalization
Ordering objects inside blueprints in regular ways for best compression, minimal git diff, etc.

---
Expand All @@ -102,5 +132,5 @@ Should also probably subdivide the examples folder into subfolders like `rail`,
And give each folder their own README.md that describes what each one does

---
### Investigate a Cython rewrite in efforts to make the library as performant as possible
### Investigate a Cython/Rust rewrite in efforts to make the library as performant as possible
Likely the last-most step, once all other feature requests and optimization passes are complete, to help squeeze as much out of the code-base as possible
62 changes: 62 additions & 0 deletions changelog.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,68 @@
* `draftsman-update` will issue a warning if it cannot specify the correct Lua version: It'll still try to load and may still work anyway, but it's not guaranteed to
* Patched InvalidModVersionError for now (#51)

* Updated `factorio-data` to version `TODO` (latest stable)
* Updated `compatibility/defines.lua` to `TODO` (latest stable)
* Swapped from `schema` to `pydantic`
* Format for specifying schemas is now much clearer
* Because the backend of `pydantic` is in Rust, it should also be faster
* Both blueprintables and entities now share the same exporting code, overall making more sense
* Can now create a JSON schema of any entity or blueprintable (by calling `Object.json_schema()`), which can be exported and used in any other program that reads JSON schema(!)
* However, minimum Python version is now 3.7 to support type hints

* Switched from `unittest` to `pytest` (more features with similar syntax; `coverage run` still works the same)
* Changed the code to be primarily Python3 compatible
* Added `data.fluids` module with some useful helpers
* Added `data.items.fuels` which is dict of sets of item names that fall under their respective fuel categories
* Added `extras` module which implements some handy new features:
* Added `flip_belts(blueprint)` which flips all belt entities inside the blueprint (preserving continuity)
* Added a bunch of equivalent functions from Factorio StdLib:
* Added `opposite()`, `next()`, `previous()`, `to_orientation()`, and `to_vector()` to `Direction`
* Added `Orientation` class, similar to `Direction`; comes with it's own suite of `__add__()`, `to_direction()`, and `to_vector()` helpers
* Added `constants.Ticks` enumeration which contains `SECONDS`, `MINUTES`, `HOURS`, etc. stored as quantities of Factorio ticks
* Added `union`, `intersection`, and `difference` to `EntityList`, `TileList`, and `ScheduleList`
* Added `TrainConfiguration`, which allows you to specify entire trains with strings like `"1-4-1"` and customize them on a per-car basis
* Added `WaitCondition` and `WaitConditions` objects which keep track of train station condition trees
* `WaitConditions` can be combined using bitwise `and` and `or` in order to collect them into a `WaitConditions` object:
* Added `WaitConditionType` and `WaitConditionCompareType` enumerations
* Added `Collection.add_train_at_position()` and `Collection.add_train_at_station()` to make placing trains easier
* Added `Collection.find_trains_filtered()` to allow users to search Blueprints/Groups for trains of particular types
* Added `RailPlanner` (finally)
* Added `index` attribute to all `Blueprintable` types, which allows the end user to customize the index in a parent BlueprintBook manually
(Still autogenerated based on list order if unspecified, but now *can* be overridden)
* Added data functions `signals.add_signal()`, `tiles.add_tile()`, `entities.add_entity()`, etc. which allow you to add entities on the fly (primarily for Factorio environment compatibility)
* Fixed a bunch of warts in the API:
* Added the ability to modify `x` and `y` attributes of both `position` and `tile_position` and have each other update in tandem
* Made it possible to rotate objects in parent `Collections` as long as they're either square or rotated such that they preserve their original footprint (akin to Factorio)
* Added `__eq__` operators to pretty much all draftsman things (`Entity`, `EntityList`, `TileList`, `ScheduleList`, `Schedule`, `WaitConditions`, etc.)
* Added more professional `__repr__` functions to pretty much all draftsman things as well
* Added `RequestItemsMixin` to `Locomotive`, `CargoWagon`, and `ArtilleryWagon`
* Added `unknown` keyword to all entity/tile creation constructs which allows the user to specify what should happen when draftsman encounters an entity it doesn't recognize
* Changed `InvalidEntityError` and `InvalidTileErrors` so that they now try to detect a similar tile/entity name and display that information to the user in the error message
* For example, if you accidentally type `Container("wodenchest")`, it will realize you probably meant to type `Container("wooden-chest")` and suggest that to you instead
* Renamed `instruments.index` to `instruments.index_of` and `instruments.names` to `instruments.name_of` to reduce confusion with local names
* Added a bunch of new documentation to document the above
* Added a bunch of new examples to test out the above new features
* Added a fixture that ensures that Draftsman is running a vanilla configuration before running tests, and exits if it detects that it is not the case.
* Added a new command line option for `draftsman-update` `--lua-version`, which prints the version of Lua currently being used for debugging compat issues
* Added a README.md to the `examples` folder which provides short descriptions for all of the examples
* Integrated aforementioned examples into the test suite
* Normalized all import filenames to use underscores consistently (potentially breaking change!)
* Finished up documentation on `DeconstructionPlanner`
* [PERF] Reduced memory consumption by up to ~80 percent(!) (This also made it quite a bit faster to boot)
* Made it so that default `collision_mask` keys are resolved at once at the data level when you call `draftsman-update`, so you can query `entities.raw` for the correct default value
* Bumped Lupa to 2.0 which allows me to specify Lua version 5.2 which Factorio uses (#50)
* `draftsman-update` will issue a warning if it cannot specify the correct Lua version: It'll still try to load and may still work anyway, but it's not guaranteed to
* Patched InvalidModVersionError for now (#51)

# 1.1.0
* Added a number of missing prototype objects that are blueprintable:
* `SimpleEntityWithOwner`
* `SimpleEntityWithForce`
* `PlayerPort`
* Fixed an issue where color settings were not recognized in the settings stage (#103)
* Fixed issue loading IndustrialRevolution modpack (regression) (#98)

## 1.0.6
* Updated `factorio-data` to version `1.1.88`
* Updated `compatibility/defines.lua` to `1.1.88`
Expand Down
Loading

0 comments on commit c15bd3c

Please sign in to comment.