Should I merge this PR?

We still need to decide on getting rid of the pinned dependencies (.txt). See my comment above.

Are there any plans to merge this in at some point?

Yes that would be great.
We have an internal deadline right now, but maybe afterwards we can return to this.

Was there anything blocking this, @Ahmad-Wahid ?

To get rid of the pinned requirements, should I just remove the files or the requirements?

The open question was if pinned dependencies should stay. Here are my thoughts:

• I'd say yes, but they should not impact what the pip-install procedure would install. Apparently, this is already the case in this PR!
• We can document in the Readme that make install-for-dev installs the exact .txt dependencies (so that devs work against the same stack), and that make upgrade-deps can upgrade these dependencies.
• We should also document that importing just via the name flexmeasures_entsoe works.
• Finally, a question: should we remove the dependency of flexmeasures from this plugin? It cannot be used on its own, it is installed by a flexmeasures installation. I think that is a good idea.

should we remove the dependency of flexmeasures from this plugin? It cannot be used on its own, it is installed by a flexmeasures installation.

I was also wondering about this with our smart-buildings plugin recently, where it isn't (yet) listed as a dependency, but I thought about including it. I haven't got a final answer, but just wanted to make an argument for including (keeping) the dependency: as a dev, if flexmeasures is installed in my local environment, it helps my IDE find imported functions and read their docstrings. So maybe include it as a dev dependency only?

Yes, we can try that.
Otherwise, for the actual dependency checking, I think it is clean to just list what the plugin requires on top of FlexMeasures' stack.