Make crates more self-contained and introduce `amethyst_core`

[torkleyy]

A few days ago I came up with an idea, hey why don't we split up Amethyst and make the creates just utility crates for Specs. While some liked the idea, @Xaeroxe was quite skeptical. And I share that skepticism. That's why I came up with a compromise:

Right now we have our crates amethyst_assets, amethyst_renderer, both of which contain their own functionality but are then wrapped in the main crate. We should instead put everything related to assets in the assets crate and the same for the renderer. This would not only solve constant complications with the orphan rules, but also allow us to make those crates optional, while still allowing easy integration and a cohesive experience thanks to the concept of ECS. Now, there are however things many Amethyst crates will share, e.g. Transform. These things should go into amethyst_core.

What should happen to the main crate?

I'm not sure if a main crate should remain, I've experimented with making a more generic state machine lately and the ecs module would essentially get dropped. Timer stuff probably goes into the core crate and fps counters and profiling tools could go into an amethyst_tools crate.

[omni-viral]

The link is slightly broken

[omni-viral]

The link is slightly broken

[torkleyy]

Fixed now, sorry

[torkleyy]

Fixed now, sorry

[Rhuagh]

Yay!

[Rhuagh]

Yay!

[Xaeroxe]

@torkleyy I guess I'm not entirely certain how this proposal solves our orphan rules problem. The purpose of the renderer crate is to render assets on screen, while the purpose of the assets crate is to allow new asset types to be defined. So when @omni-viral wants to implement amethyst_assets::Asset for amethyst_renderer::Mesh I'm still not sure how he'd do that under this proposal. Does the proposal just accept such an implementation won't be possible? Because if so we have two choices:

• Wrap Mesh ourselves in amethyst_core and implement Asset for the wrapper (similar to what we've already done)
• Ask downstream users to do the same for their own projects, which is essentially asking them to write the same piece of code for every project just to satisfy our need to separate concerns.

Basically I'm questioning the wisdom of trying to separate concerns too heavily, because these concerns might not be that separate after all.

[Xaeroxe]

@torkleyy I guess I'm not entirely certain how this proposal solves our orphan rules problem. The purpose of the renderer crate is to render assets on screen, while the purpose of the assets crate is to allow new asset types to be defined. So when @omni-viral wants to implement amethyst_assets::Asset for amethyst_renderer::Mesh I'm still not sure how he'd do that under this proposal. Does the proposal just accept such an implementation won't be possible? Because if so we have two choices:

• Wrap Mesh ourselves in amethyst_core and implement Asset for the wrapper (similar to what we've already done)
• Ask downstream users to do the same for their own projects, which is essentially asking them to write the same piece of code for every project just to satisfy our need to separate concerns.

Basically I'm questioning the wisdom of trying to separate concerns too heavily, because these concerns might not be that separate after all.

[torkleyy]

Why not make amethyst_renderer dependent on amethyet_assets?

[torkleyy]

Why not make amethyst_renderer dependent on amethyet_assets?

[Xaeroxe]

That works. That was a relatively straightforward fix haha :) Then sure I have no problem with this if we're allowing amethyst_* crates to depend on amethyst_* crates other than amethyst_core

[Xaeroxe]

That works. That was a relatively straightforward fix haha :) Then sure I have no problem with this if we're allowing amethyst_* crates to depend on amethyst_* crates other than amethyst_core

[Rhuagh]

Ofc, that would be a given, my coming amethyst_gltf would depend on both assets and renderer, as an example.

[Rhuagh]

Ofc, that would be a given, my coming amethyst_gltf would depend on both assets and renderer, as an example.

[Rhuagh]

Btw, we will need to look into error-chain or something like it from the get-go when we do this (we should anyway).

And app.rs, where does that go, amethyst_core or its own crate ?

[Rhuagh]

Btw, we will need to look into error-chain or something like it from the get-go when we do this (we should anyway).

And app.rs, where does that go, amethyst_core or its own crate ?

[torkleyy]

That's a tough question:

1. I wanted to add a similar thing to Specs, but have to wait for specialization
2. Application is incompatible with ParSeq
3. The way it currently works conflicts with the plans to give more freedom wrt dispatchers and World

[torkleyy]

That's a tough question:

1. I wanted to add a similar thing to Specs, but have to wait for specialization
2. Application is incompatible with ParSeq
3. The way it currently works conflicts with the plans to give more freedom wrt dispatchers and World

[Rhuagh]

Yeah, I kinda felt that would be the case, so my suggestion is to put it in it's own crate, so it's easy to swap out. Something like amethyst_app.

[Rhuagh]

Yeah, I kinda felt that would be the case, so my suggestion is to put it in it's own crate, so it's easy to swap out. Something like amethyst_app.

[Binero]

I think a main crate should definitely remain. When splitting up amethyst in modules, I think it's important to have the main crate to bring them all together, and to allow the user to quickly get started without too much puzzling.

[Binero]

I think a main crate should definitely remain. When splitting up amethyst in modules, I think it's important to have the main crate to bring them all together, and to allow the user to quickly get started without too much puzzling.

[torkleyy]

@Binero My point is that it's not harder and by making them modular, docs can be more focused.

I mean how is

extern crate amethyst_renderer;
extern crate amethyst_physics;

harder than

extern crate amethyst;

use amethyst::renderer::...;
use amethyst::physics::...;

? We just provide a nice example and explanation to get started. This isn't what I'd call puzzling. Additionally, these crates should require zero glue code.

[torkleyy]

@Binero My point is that it's not harder and by making them modular, docs can be more focused.

I mean how is

extern crate amethyst_renderer;
extern crate amethyst_physics;

harder than

extern crate amethyst;

use amethyst::renderer::...;
use amethyst::physics::...;

? We just provide a nice example and explanation to get started. This isn't what I'd call puzzling. Additionally, these crates should require zero glue code.

[Xaeroxe]

these crates should require zero glue code.

❤️ You have no idea how happy that sentence makes me

[Xaeroxe]

these crates should require zero glue code.

❤️ You have no idea how happy that sentence makes me

[Rhuagh]

With the exception of a single function call or two to register things in world/dispatch, but that's user code anyway

[Rhuagh]

With the exception of a single function call or two to register things in world/dispatch, but that's user code anyway

[Xaeroxe]

(he accidentally submitted his comment twice so I deleted one of them. I'm not trying to censor things I swear :P)

[Xaeroxe]

(he accidentally submitted his comment twice so I deleted one of them. I'm not trying to censor things I swear :P)

[Binero]

@torkleyy It makes it incredibly hard to read documentation, it requires the user to manage all dependencies and is non-obvious.

[Binero]

@torkleyy It makes it incredibly hard to read documentation, it requires the user to manage all dependencies and is non-obvious.

[torkleyy]

@Binero How about that:

We keep the main crate for now, which makes sense anyways because it's easier to refactor. Then, after all the other changes are made, we revisit this again and make a decision.

[torkleyy]

@Binero How about that:

We keep the main crate for now, which makes sense anyways because it's easier to refactor. Then, after all the other changes are made, we revisit this again and make a decision.

[Rhuagh]

Yeah, I'm fine with that. If it just becomes a long list of "pub extern crate amethyst_$t as $t;" so be it :)

[Rhuagh]

Yeah, I'm fine with that. If it just becomes a long list of "pub extern crate amethyst_$t as $t;" so be it :)

[torkleyy]

So @Rhuagh did #415 and #419 . Thank you!

[torkleyy]

So @Rhuagh did #415 and #419 . Thank you!

[Xaeroxe]

I think we're done here. Re-open if you disagree with me.

[Xaeroxe]

I think we're done here. Re-open if you disagree with me.