1141776 - (remove-cfx) [tracking] Delete CFX.py

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P4)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

We should remove all of the legacy cfx related python from the addon-sdk code base.

We do not want to release a new version of it or maintenance code in this directory https://github.com/mozilla/addon-sdk/tree/master/python-lib so I feel we should remove it as soon as possible so that we are not forced to maintain it when it inevitably breaks/rots on us.

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

My general thinking here is this:

When we released cfx 1.17 we made a commitment that the high level apis available then would work with an add-on generated with cfx for as long as possible without needing upgrades (google "the last great repack").

Also, it is not possible to repack cfx add-ons to jpm add-ons in every case, a great number could be auto converted, but any that depend on third party modules would be difficult and since the default structure is different many code changes would need to be made.  In general I would not advise this path, and we already claimed a last great repack, so let's leave it at that.

So, in order to continue supporting cfx generated add-ons without continuing to support cfx, I propose we make some pre generated cfx add-ons to cover all of the use cases we currently cover (ie test add-ons) in folders which will then only need to be xpi'd in order to be used.

Since we also want to be able to make changes to our high level modules tests, I think we will need to either write a script to copy to module test files to these pre generated cfx test folders, or we can perhaps create a resource://test-addon-sdk which is only used while testing these cfx test folders, or perhaps we can come up with something better?

Thoughts?

Comment 2

[Dave Townsend [:mossop]]

(In reply to Erik Vold [:erikvold] (please needinfo? me) from comment #1)
> So, in order to continue supporting cfx generated add-ons without continuing
> to support cfx, I propose we make some pre generated cfx add-ons to cover
> all of the use cases we currently cover (ie test add-ons) in folders which
> will then only need to be xpi'd in order to be used.

Sounds good to me.

> Since we also want to be able to make changes to our high level modules
> tests, I think we will need to either write a script to copy to module test
> files to these pre generated cfx test folders, or we can perhaps create a
> resource://test-addon-sdk which is only used while testing these cfx test
> folders, or perhaps we can come up with something better?

I don't know how much effort this is worth but yeah seems reasonable we could make the test map a fixed directory to include additional tests. Either that or we just use the same directory for both, stripping out the cfx-parts before testing elsewhere somehow.

Comment 3

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Don't we already map local sdk files so that they will be loaded when required instead of ones in firefox. I would expect we can make pre-packed cfx based test add-ons in order to test that they continue working with an API changes.

Larger question is how long do we expect to support them in this manner ? I imagine at some point we would need to either break or repack them. How does our current deprecation process fits this picture ?

Comment 4

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562