I recently had the issue that I needed to use the \Magento\Eav\Setup\EavSetup outside the setup-context.
To be a bit more concrete, I wanted to import attribute-sets, attributes and attribute-options without using an install-script.
My first idea was

in magento2 you can easily inject the ‘EavSetup’ via constructor injection and then use it in your own class

First try

So I injected into my class which worked out well in the development-mode.

/**
 * SomeAttribute constructor.
 *
 * @param \Some\Own\AttributeContext $context
 * @param \Magento\Eav\Setup\EavSetup $eavSetup
 * @param string $entityTypeId
 *
 */
public function __construct(
    \Some\Own\AttributeContext $context,
    \Magento\Eav\Setup\EavSetup $eavSetup,
    $entityTypeId = Product::ENTITY
) {
    parent::__construct($context);

    $this->eavSetup = $eavSetup;
    $this->entityTypeId = $entityTypeId;
}

But using the same code with the production-mode a fatal error occurred with a message like

ERROR: PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Magento\Setup\Module\DataSetup::__construct() must be an instance of Magento\Framework\Module\Setup\Context, 
instance of Magento\Framework\ObjectManager\ObjectManager given, 
called in [...]/src/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 93 and defined in [...]/src/setup/src/Magento/Setup/Module/DataSetup.php:57

After a short research and some debugging, it turned out that the “production”-mode was not the issue. The root of the problem was the output “setup:di:compile”-command created. And more over how the EavSetup is instantiated in general.

A brief digression

For better testing I wrote a short php-file which tries to instantiate my class with the help of the object-manager. It is based on the ‘index.php’ without the $bootstrap->run($app); line, instead of the run-method I call “getObjectManager” and work with the object-manager for my tests.

With these information I started my analysis how magento does it and how could I use the “EavSetup” for my purposes.
Here you can see some classes that are relevant in instantiating an EavSetup:

• \Magento\Setup\Model\ObjectManagerProvider
• \Magento\Setup\Module\DataSetupFactory
• \Zend\ServiceManager\ServiceManager
• \Magento\Framework\ObjectManager\Factory\Compiled::create
• \Magento\Framework\ObjectManager\Config\Compiled::getArguments

The main issue was that \Magento\Framework\ObjectManager\Config\Compiled::getArguments  did not return the correct arguments.
So while I was not able to pass the arguments as needed, I had to figure out another way how to use the “EavSetup” in my class.

After debugging the magento instantiation of the “EavSetup”, I started to forge the magento process in my construct.

The Solution

The resulting solution looks something like this

/**
 * SomeAttribute constructor.
 *
 * @param \Some\Own\AttributeContext $context
 * @param \Magento\Eav\Setup\EavSetupFactory $eavSetupFactory
 * @param string $entityTypeId
 *
 */
public function __construct(
    \Some\Own\AttributeContext $context,
    \Magento\Eav\Setup\EavSetupFactory $eavSetupFactory,
    $entityTypeId = Product::ENTITY
) {
    parent::__construct($context);

    $serviceLocator = new \Zend\ServiceManager\ServiceManager();
    $serviceLocator->setService(\Magento\Setup\Mvc\Bootstrap\InitParamListener::BOOTSTRAP_PARAM, []);

    $provider = new \Magento\Setup\Model\ObjectManagerProvider($serviceLocator);

    $dataSetupFactory = new \Magento\Setup\Module\DataSetupFactory($provider);
    /** @var \Magento\Framework\Setup\SchemaSetupInterface | \Magento\Framework\Setup\ModuleDataSetupInterface $setup */
    $setup = $dataSetupFactory->create();
    $this->eavSetup = $eavSetupFactory->create(['setup' => $setup]);
    $this->entityTypeId = $entityTypeId;
}

Let me just explain in a few words what I had to do.

For a better understanding let us move from bottom to top, my goal was to create a “EavSetup” instance to reach this goal I had to use the EavFactorySetup->create()  method.
The EavSetupFactory has a dependency to the DataSetupFactory which itself needs a ObjectManagerProvider instance injected.
This is the interesting point in this manual dependency injection flow:
the ObjectManagerProvider now needs a ServiceManager to create the instance.  
That’s the main cause of our issue with di:compile and production mode. This dependency cannot be injected by the default ObjectManager and thus the above mentioned error occured.

So after manually building the dependencies and creating the objects, we could work around this issue.

In case you haven’t seen how the “setup/index.php” “application” works you should have a closer look at that.