Feature/engine paths #114

wants to merge 3 commits into


None yet

3 participants

KensoDev commented Jul 4, 2012

Fabrication was not working with Engines, the fabricators folder was expected to be inside the dummy app
this pull request fixes it.

  • Refactored the code to extract Rails constant, so I can stub it in the specs
  • Added specs to the engine path.
  • All suite passes, resynced with master right before I pushed this one.

I don't think this is an appropriate thing for Fabrication to handle. If you need to load fabricators from an engine or anywhere else, you can add to the fabricator search path.


@paulelliott paulelliott closed this Jul 6, 2012
KensoDev commented Jul 6, 2012

@paulelliott When I tried it, this didn't work and it seemed that the path is always relative to the Rails.root.
When you are working on an engine, the path is outside of the rails root, since the app sits inside spec/dummy.

Nothing I did seemed to work, that is why I decided to have the core of the library handles it.

Bottom line
The configuration is not working for me if I want to configure the engine outside of the app (like in a rails engine)


What is the path of the engine and of your Rails app?

KensoDev commented Jul 6, 2012




Can you try adding this under spec/support/fabrication.rb in the Rails app? Unless I am missing something, this should work.

Fabrication.configure do |config|
KensoDev commented Jul 7, 2012

I don't want the fabricators inside the spec app inside the dummy app.
I want the fabricators in the folder where my engine lives.

If I wanted it inside the app, this is already working perfectly.

This is the folder structure I want

The fabricators are in the spec directory for the engine, outside the dummy app.


@paulelliott News on this?


The code in this pull request uses paths that are hard-coded for your application. I am not totally opposed to adding in some sort of support for engines, but if we do then it needs to be more flexible. We may be able to include engine_paths as a configuration option instead and run the code based on the values presented there. Requiring them to be supplied like that would mean that we don't need to do any lookups at all.

@paulelliott paulelliott reopened this Jul 12, 2012

Found myself in the same situation where Fabrication indeed looks inside the test folder of the dummy app.
I have to agree with KensoDev that this isn't the right place to store them. But at the same time i agree with paulelliott that the code in the pull request looks a bit hackery :)

can't we just make the path_prefix configurable (not obligatory)? This way, someone that uses engines, can set the path_prefix to MyEngine::Engine.root .

If path_prefix has not been configured, use the existing logic ( if Rails defined, use Rails.root, else ....)


I agree that this seems hackery.

IMHO the gem still needs to add support for that, because in the current situation the gem is not usable when you are working on an Engine.

So... What are the suggestions? What do you think is a good solution?
I would be happy to implement


I have opened a pull request #116 for a small patch (#116) that makes the path_prefix configurable.

Using this patch at the moment and it's working for me.


Version 2.2.0 has pull request #116 merged in so you can now specify the path prefix for your engine.



That is awesome, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment