Added partial Azure files support to the SDK

[schaefi]

With this initial implementation support for

• adding a share
• listing shares
• deleting a share

has been added

[huguesv]

Thanks for the submission!

We are in the process of reorganizing the SDK by splitting it into multiple PyPI packages. This is going on in the dev branch of this repo, and things are still in flux right now. We'll also be transferring ownership of the storage part of the SDK to the storage service team (and have it move to its own repository).

Right now our plan is for the next release of the SDK to be from the code in the dev branch. This means we won't be taking these changes in the master branch. We'll give you some advice when the dev branch stabilizes and we're ready to take in your functionality, as this will require several changes to your submitted code.

[rjschwei]

You are kidding right? This is about the lamest reason I have ever seen for not accepting a pull request. As a project maintainer your job should be to encourage contributions and not send people away because of some other work that is not mentioned or advertised anywhere else. Marcus did a lot of work and others spent time reviewing the code and discussing implementation options.

I urge you to reconsider this and follow commonly accepted practices. Accept work that meets coding quality and implementation practices of the project. The restructuring should not be a burden to those that are trying to contribute.

[schaefi]

Apart from that this makes collaboration a really hard task, and I agree to what Robert said, what holds you back to merge feature pull request into master and after that starting such a restructuring process ? In addition if you plan for such changes you should notify people before or at least add a comment in the initial README page of this project.

If you reflect this would have happened to you, would you have much motivation left to adapt an already working feature to a changed project structure ? This is how opensource projects can be killed or forked apart

[emgerner-msft]

Hi Robert & Marcus,

We appreciate and want to encourage contributions to the library and thank you for your patience in this case. In the future, we will try to communicate larger changes better. At the same time per the contribution guidelines linked to in our README, it would be helpful if before you start working on a substantial code contribution that you discuss it with the team. In this way we can communicate with you details of any changes that may affect the feature as well as contribute to your design process to ensure we can accept the resulting code.

In the case of this particular pull request, we would like to build on your work whilst we complete support for the entire file service. This work is currently being developed in the “dev” branch and we plan to release in late August. This should meet your needs for the feature as well as give folks more complete support for the service. Rather than accept the pull request directly we will copy some of your work over to the new implementation. We are definitely excited to have you continue to contribute moving forward – hence if this approach causes any grief lets schedule a call and discuss options for moving forward.

Thanks,
Emily

[schaefi]

Hi,

Thanks for the update. I have ported this pull request to the dev branch you plan to release in August. I hope I understood the basics of the new structure correctly and appreciate a review of
the new pull request. Adding the rest of the file share service api should be a possible task now

it would be helpful if before you start working on a substantial code contribution that you discuss
it with the team.

I agree completely and would like to do that. However I'm not clear what is currently the best way to get in contact with the team other than sending some code along :) Please advise, is there a mailing list ? regular team metting ? any kind of communication you prefer I can adapt to. Thanks much

Regarding this I would like to bring up that your current restructuring impacts existing
implementations. I found the following namespace compatibility issues:

• BlobService import path is now azure.storage.blob before it was azure.storage
• WindowsAzureXXXError import path is now azure.common before it was azure

Not sure if you plan to care for this but I'd like to mention it

We are definitely excited to have you continue to contribute moving forward – hence if
this approach causes any grief lets schedule a call and discuss options for moving forward.

I'm also highly motivated to take part in this project, especially because I'm also writing the azurectl
management tool based on this SDK. On my todo is also support for the publishing and replication api.

I hope the pull request against the dev branch suits you better and follows your current workflow

I'm going to close this one now

[schaefi]

Closing: a new PR for the dev branch was created: #424

[emgerner-msft]

We can discuss the new pull request on the other thread; here I just want to make sure we answer all your questions!

Communicating with the storage team:
A great way to contact us is to open an issue, or comment on an existing issue. In this case we already had an issue open to track the file service feature which would’ve been a great place to start a discussion. Issues are also a great way to ask for a feature, whether or not you intend on contributing code.

Restructuring changes:
This reorganization in part to facilitate the storage code moving to a new repository but also to reorganize a code base that has grown a lot since its inception. With the proliferation of storage services (ex file) we thought this would also be a good time to separate the storage services into their own subpackages. We do realize this is a break, but we hope a more organized package system will make our API more usable and extensible in the future. As Hugues mentioned, dev is currently not stable and part of that instability is in the error classes. There may be breaks, but we’re not sure yet exactly where things will land.

Further projects:
I personally don’t know much about azurectl but if you’d like to chat with storage folks at any point about it, feel free to email jahogg at microsoft dotcom and we can set up a call. Per above, if you have specific contributions in mind opening an issue is the best way to go.

Best,
Emily

[schaefi]

Appreciate your feedback

Communicating with the storage team: A great way to contact us is to open an issue

Thanks, I'm going to to use the github issue tracker

Restructuring changes: This reorganization in part to facilitate the storage code moving to a new repository but also to reorganize a code base that has grown a lot since its inception. With the proliferation of storage services (ex file) we thought this would also be a good time to separate the storage services into their own subpackages. We do realize this is a break, but we hope a more organized package system will make our API more usable and extensible in the future. As Hugues mentioned, dev is currently not stable and part of that instability is in the error classes. There may be breaks, but we are not sure yet exactly where things will land.

That's fine for me, I just wanted to see if you are aware of it. I like the new structure better than the old one and for me personally and the application I use the SDK for it's not a big problem to adapt to the change. However I could imagine other projects might be surprised. I think once you know 0.20.x will be incompatible to 0.11.x it's at least worth an information on the project page

Further projects:

Thanks for the details, I definitly will make use of the issue tracker for further contacts Regards, Marcus