moving to pypi, new tools, a few bug fixes

[cbernet]

Packaging:

• package restructured for pypi: https://pypi.org/project/heppyfwk/. We can now pick up heppy in pypi for the FCC suite like other python packages instead of distributing the code.
• enable the use of heppy with plain ROOT files, and with input files readable in bare python (numpy, text, etc)

Physics tools:

• Resonance leg extraction now in separate module
• Jets:
  • Jet components: the particle list of the jet was copied, which was slow. Not the case anymore
  • Jet constituents now has a method to return the number of ptcs, and the number of charged hadrons
  • The JetClusterizer has been made more flexible. Possibly backward incompatible, WARNING.
  • Jet charge is now computed
  • bug fix: can now print jets that were deepcopied
• Isolation:
  • veto area can now be defined
  • bug fix: negative e and mu in the isolation cone where considered as charged hadrons
  • consistently use theta instead of eta in ee mode
  • can now remove a particle from isolation info (final state radiation recovery)

Papas detectors:

• CLD:
  • refactoring
  • geometry updated (fixed)

Other tools:

• added Tagger analyzer
• added EventByNumber (selects a given event) and EventSkipper, useful for debugging
• genbrowser: bug fix in self decays (e.g. photon radiation)
• added text input backend (to process text files)

[cbernet]

@vvolkl @JavierCVilla Here it is. Valentin, I will include your changes in all your PRs as soon as this one is merged if you agree. Javier, not sure what needs to be done for the integration tests... the heppy test suite is working, but we should make sure it is used properly in Jenkins.

[vvolkl]

Great! No problem, it should be easy to rebase my PR's once this is merged. I can do a review tomorrow.

[cbernet]

@vvolkl for your review, maybe you just want to look at the differences between master and bc354d0c, before the big restructuring for pypi. It's going to be easier for you I guess. Thanks!

[JavierCVilla]

This is what I meant with my comments on #89 , it is quite though to review all these changes on a single PR, even to test it. For the future, we should try to break this down into smaller PR's.

[cbernet]

There are not many changes apart from the pypi restructuring. If you want I can do a first PR before the pypi restructuring, and then another one?

Anyway are you sure you want to review this code? Are you a heppy user? Maybe @clementhelsens would be a good candidate.

[JavierCVilla]

There are not many changes apart from the pypi restructuring.

Well.. there are 1,634 lines added and 864 deleted, I think it is a considerable amount of changes.

Anyway are you sure you want to review this code?

Absolutely not...

Are you a heppy user?

.. and no, i'm not. I don't think I'm in position to review this code, but I do think that for the sake of the maintenance, we should avoid PR's of this size.

For instance, there are changes related to heppy functionality and changes related to the pypi restructuring. I guess now heppy gets installed through pip, so the CI will never work because it uses a different mechanism to build and test the package. Alternatively you can first change the CI, however in that case you are not testing the changes related to heppy functionality.

Also, once this have been merged, the new version should be directly 3.0.

Said that, these are only my two cents.

[cbernet]

I'm sorry Javier, but it appears you might have misunderstood my post.

I said that there are not many changes apart from the pypi restructuring and you give me the total changes in this PR including the pypi restructuring :-)

Most of the changes come from the pypi restructuring, and there is nothing we can do, this is big, even if I had done a PR specifically for that.

I understand your point about having smaller PRs and I agree. So I proposed to make 2 PRs: one for what comes before the pypi restructuring (@clementhelsens could review it), and one of the pypi restructuring. that's precisely what you asked for : smaller PRs.

So would you like me to close this PR and replace it by the two smaller ones?

[JavierCVilla]

The thing is that even if the vast majority of changes are related to the pypi restructuring, it is hard to distinguish. So one may need to go line by line on the review anyway.

I understand your point about having smaller PRs and I agree. So I proposed to make 2 PRs: one for what comes before the pypi restructuring, and one of the pypi restructuring. that's precisely what you asked for : smaller PRs.

So would you like me to close this PR and replace it by the two smaller ones?

IMO it would be the right way to do it.