You have taken the spf import name already belonging to pyspf

[sloev]

Hi
i recently raised an issue (and contributed a PR) to the project pyspf since their module is imported as spf like yours and i need both

they replied with

This project has been using the spf module name since 2004. 
I think it would be ridiculous for us to rename because of a less 
than three year old project that obviously failed to evaluate
the name space before using it. 
...
Typically in the case of a namespace conflict, it's the newer 
project that renames. The structure of the package reflects it's age.

so what are we gonna do?
currently i cant import both and it makes me a sad panda 😭

here is the PR:
sdgathman/pyspf#20

and the issue is pyspf-module_name==sanicpluginsframework-package_name

• https://github.com/sdgathman/pyspf/blob/pyspf-2_0-branch/setup.py#L21
• https://github.com/ashleysommer/sanicpluginsframework/blob/master/setup.py#L50

kind regards
Johannes

[ashleysommer]

Hi @sloev
Thanks for bringing this to my attention.
Lets hope I can handle the situation with a bit more civility than the pyspf project owner.

I actually did look into whether any other projects use the spf import name before publishing the first version of sanic-plugins-framework, but evidently I didn't look deep enough.

So although sanic-plugins-framework has more than double the number of downloads-per-month, Johannes is right, it is us that will need to change our import name.

I have a major update to sanic-plugins-framework in which I intend to switch from using a setup.py-based project to a pyproject.toml project orchestrated with poetry. It will be released as either 0.10.0 or 1.0.0. It would make sense that then is a good time to also change the project package name. I'm thinking probably spfw or sanicpf.

So the plan will be that if you want to use pyspf and sanic-plugins-framework in the same project, you will need to use sanic-plugins-framework>=0.10.0.

The main issue will be with sanic plugins written to use spf. I'm the maintainer of 6 different spf-based plugins, so I can add graceful import handling to those, I'll attempt to contact the maintainer for any others I know about, but for the rest we'll hope they find the change themselves in their testing, or they simply stick with sanic-plugins-framework<0.10.0.

[sloev]

Thank you for a nice civil reply 😅
I will consider this solved in the (near) future and move on with my rainy day 😬

Have a great 2020!
Kind regards

[ashleysommer]

As it gets closer to the end of 2020, I'm still well aware I have not addressed this issue.
The main reason is I want to be very careful about keeping backward compatibility with existing versions of SPF.

Eg, if PluginA uses Sanic-Plugins-Framework == 0.9.4, but PluginB uses Sanic-Plugins-Framework >= 0.10.0, we might get both "spf" and "spfw" packages imported at the same time. With PluginA using the former and PluginB using the latter.
This is not good news if the plugins need to interact with each other, eg using the SPF Shared Context mechanism, or need to be in the same Middleware Stack.

I have some ideas how to tackle this issue, but it will take some time.

[ashleysommer]

Update on this issue:

Sanic 21.03 coming in March 2021 will be a BIG update. There are several big features that have been simmering for the last 12 months that are finally being merged in, which means we'll need some major changes in SanicPluginsFramwork too.

The current series of SPF will only work on Sanic up to 20.12.x.
This is a good opportunity to break backward compatibility with older versions of SPF, and we can finally do our name change.

[ashleysommer]

Sanic-Plugins-Framework project is now renamed to Sanic-Plugin-Toolkit.
The module name is renamed from spf to sanic_plugin_toolkit.
Sanic-Plugin-Toolkit v1.0 is now released, it is compatible with Sanic 21.3+ only.
Fixed by d1a3156