Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add check_prerequisite and cache helpers #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ThomDietrich
Copy link

@ThomDietrich ThomDietrich commented Oct 8, 2017

Transferred from basnijholt#36

This PR adds a check for prerequisites to the backend definition. In case of gatttool we need to check if it is available prior to using the functions write_ble/read_ble.
Furthermore I've added two helper functions: It might be important to know that data is available in the cache and in certain situations one might want to purge the cache manually.

@ChristianKuehnel this might be a bit surprising. I've taken your latest PR as the base for this fork. The PR is a small addition that might turn out helpful. Wdyt?

@ChristianKuehnel
Copy link

@ThomDietrich yes, that makes sense. 😃

@ChristianKuehnel
Copy link

@ThomDietrich sorry, maybe a stupid question:
What's the purpose of this fork? Do you want to maintain a new version of the library as there is no progress in the original repo?

What about releases to pip?

@ThomDietrich
Copy link
Author

ThomDietrich commented Oct 9, 2017

Yes. Let's call it a parallel version. I have no intentions of pissing anyone off and would love to see progress in the original repo at a later point.

However up to now there has not been much progress and the communication was sparse at best. I've developed a project with the library as a dependency and needed a few additions. After patiently waiting for a few weeks I believe it's time to take matters into our own hands. (Again: I would still be interested in a solution which everyone is comfortable with)

The rejuvenate community was created by a few others and myself with such cases in mind. The fork is supposed to be maintained by more than one person (the community). I've invited you to the organization to take part, if you want to.

Regarding pip: Eventually we could do that, for now it would suffice to use the repo as a package source directly, wouldn't it?

Best! Thomas

@ChristianKuehnel
Copy link

ChristianKuehnel commented Oct 10, 2017

Hey Thomas,

I was thinking about your proposal and I get your point. On the one hand, I think open source is about agility, quickly delivering new features and focusing on technical issues. On the other hand it's about collaboration and a community effort. For me it's also about keeping the project together and not waste previous time on parallel implementations of the same functionality.

That being said, I just opened an issue (basnijholt#41) with the original project so see if they are willing to take on new maintainers so that we can revive the original project. If that does not trigger any reaction, I'm willing to switch over to your parallel version to bring the library forward.

By the way: thank you for the invitation!

@ThomDietrich
Copy link
Author

That would indeed be the more favorable solution! Let's see.

@ChristianKuehnel
Copy link

I have mega permissions on the upstream repo now. So I'll try to merge my changes there...

@ThomDietrich
Copy link
Author

Very happy to see that worked out! I'm currently traveling. As soon as I'm back I'll delete the fork here and update the original PR of the one here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants