search

thinkle / gourmet

Gourmet Recipe Manager
GNU General Public License v2.0
341 stars 142 forks source link

Call for more Gourmet developers and maintainers #897

Open holocronweaver opened 6 years ago

holocronweaver commented 6 years ago

It is clear the gourmet repo has fallen into disrepair.

HEAD of master has been broken for over almost two years with no commits since, pull requests and solved issues are not being merged, even simple bug fixes are not being implemented. The code is in need of quite a few updates to catch up to its dependency libraries. Not to mention the looming Python 2 discontinuation issue.

Suffice to say the project needs a few active maintainers who can handle pull requests so that bug fixes and new features steadily merge in and the project gets up off the ground again.

The path forward seems clear:

Once those two are satisfied, the project can resume.

So this is a general call for developers who want to help Gourmet get back on its feet.

If we have a few active maintainers and regular-ish contributors it should distribute the workload enough so that one or two people leaving at a time won't grind the project to a halt, and even if the lead maintainer takes a break the project will carry on in their absence.

If you enjoy Gourmet like I do, please help keep it alive and growing!

holocronweaver commented 6 years ago

I can help get master in good condition. I am also willing to help resolve issues and handle pull requests. Definitely don't have enough time to do it all on my own, but with a few other active maintainers we should be able to make it work.

thinkle commented 6 years ago

fwiw, I've been using gourmet on a regular basis throughout this time, but haven't been pushing changes to the repo. I just pushed a bunch of fixes.

I've had in my mind a major gourmet development push for some time, but I think a big push would involve abandoning the platform entirely and building out a web-based gourmet that could be easily accessed from mobile, etc. -- the universe has changed a lot since I started this project, which was before the iPhone existed, etc. :)

In the mean time, I'm happy to keep pushing fixes as I see them and I'll certainly look at pull requests. That said, I'm more tempted to start a fresh project (webgourmet?) to move this thing to a modern web-friendly/mobile-friendly architecture than I am to go through everything and convert to python 3 and the new gtk bindings.

holocronweaver commented 6 years ago

Holy cow! I did not expect such an immediate deluge of commits. I encountered a few bugs in initial testing, will create issues. But this is great, master runs for me again!

If you could use help maintaining the project, don't hesitate to reach out to us. Maybe tag issues that are up for grabs. At the very least I'll bugfix + pull request as I go and tackle a few issues a month.

Making Gourmet mobile-friendly would be a dream come true and is the main thing I wanted to contribute to the project. Currently I export MCB files to NextCloud, then import into My CookBook Pro on my phone. This works well for me, though it requires a couple manual steps. A more tightly integrated approach would be awesome.

I strongly prefer native apps both on desktop and mobile for performance, looks and usability, but I see no reason Gourmet couldn't switch to a client-server architecture to let people develop whatever clients they desire and pick the server host that works best for them (or host it themselves!). This would also allow users to continue the traditional Gourmet experience via client+server on a single host if they want, making the transition more seamless.

Top of my wishlist:

I'll open a new topic to gather ideas and a project timeline for Gourmet 2: Rise of the Mobile Devices.

rhs-github commented 6 years ago

Posted this about a month ago. Nothing has happened with that to this point. Its a patch already! Also I have autopep8'ed every module in existing code, removed all white space, indentation errors, stale code I could for the last month. I have an entire list of stuff to work on, i.e. non functional methods. I got the existing scrape to work, it was missing a critical "import". I totally agree with updating the nutrition data base. What is it exactly that I need to do? rs

holocronweaver commented 6 years ago

Hi @rhs-github. I am not sure what your question is. Are you asking how to submit a pull request?

rhs-github commented 6 years ago

Sorry, was pushed for time. I'm just contemplating several things namely:

Having said that here is what my own crystal ball would like to predict: -try to remain as code agnostic as possible. Removing dependencies on other distros/public repositories would be a priority. Python has plenty of mutable objects to play with. I realize that this is not possible with all things, but in' order to proceed this has to be on the table. -gourmet at present is a gnu/gnome/qt project using python as the glue. Please let me know how you feel about this. I am no python expert but I like the ease of formatting and a relaxed form of syntax. Python also seems to like trying methods first (without a lot of checking) and then either failing silently or allowing a capture and redirect. That's my 2 cents on python. The really nice thing about python applications (and I consider this to be HUGE) is the speed at which they 'MAKE' and install. -switch to python3 should be a goal as well. 2 is gone in 2020. -ideally there should be a collaborative effort at the minimum involving Linux, Windows, FreeBSD developer(s). The more the more successful the new branch will be. -there seems to be a call for a mobile application. In my mind this is an entirely separate branch, even application. Gourmet is a huge application and getting it mobile is not one of my goals. Sorry.

Take me to your leader! Rick

thinkle commented 6 years ago

On Wed, Feb 21, 2018, 12:50 PM rhs-github notifications@github.com wrote:

Sorry, was pushed for time. I'm just contemplating several things namely:

  • to proceed it would be good to have a plan(s).
  • this means a review of what has been, and, what needs to be.
  • then attainable goals can be set. This kind of thing makes everyone generally happy cause they then know what the heck is going on before even attempting anything. Its a kinda unification if you will.

Having said that here is what my own crystal ball would like to predict: -try to remain as code agnostic as possible. Removing dependencies on other distros/public repositories would be a priority. Python has plenty of mutable objects to play with. I realize that this is not possible with all things, but in' order to proceed this has to be on the table.

I'm not sure I follow. Do you mean language agnostic?

-gourmet at present is a gnu/gnome/qt project using python as the glue.

There's no QT in this project. It is definitely a gtk project.

Please let me know how you feel about this. I am no python expert but I

like the ease of formatting and a relaxed form of syntax. Python also seems to like trying methods first (without a lot of checking) and then either failing silently or allowing a capture and redirect. That's my 2 cents on python. The really nice thing about python applications (and I consider this to be HUGE) is the speed at which they 'MAKE' and install. -switch to python3 should be a goal as well. 2 is gone in 2020.

Yes, the frustrating thing here is that the newer gtk bindings aren't as nicely documented as the gtk2 ones were. If someone wants to take the time to upgrade to python3 + the new gtk bindings I'm happy to accept the effort, but I don't anticipate doing it myself. If 2020 rolls around and I haven't built a totally new front end, then I will probably grudgingly do it at that point rather than let the project slide into obsolescence.

-ideally there should be a collaborative effort at the minimum involving

Linux, Windows, FreeBSD developer(s). The more the more successful the new branch will be.

Not sure what you imagine. Generally there are some packagers needed on different distros and OSs, but that's it.

-there seems to be a call for a mobile application. In my mind this is an

entirely separate branch, even application. Gourmet is a huge application and getting it mobile is not one of my goals. Sorry.

Take a look at my draft roadmap - it's more about moving to the cloud than just supporting mobile.

Take me to your leader!

Rick

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-367411615, or mute the thread https://github.com/notifications/unsubscribe-auth/AAi8W8fc65SkUHhKcR1IN3ac1TSOKrCHks5tXFdmgaJpZM4R4cMI .

FriedrichFroebel commented 6 years ago

I would be interested in supporting the application to be ported to Python3 and the current GTK3 bindings. Do you still want to maintain compatibility to the old Python2 or would you like to aim a complete Python3 port?

While having a first look at the code, there are some other things I am not sure at first sight (only by looking at the setup and the module init file):

Additionally, the psyco module is deprecated, see http://psyco.sourceforge.net/, so we should probably have a look at alternative JIT compilers (or drop this feature completely).

thinkle commented 6 years ago

On Thu, Feb 22, 2018 at 9:38 AM, FriedrichFroebel notifications@github.com wrote:

I would be interested in supporting the application to be ported to Python3 and the current GTK3 bindings. Do you still want to maintain compatibility to the old Python2 or would you like to aim a complete Python3 port?

I think a complete port probably makes sense. I'd say it makes the most sense to create a branch for this work and only merge into head when it's completely feature compatible.

While having a first look at the code, there are some other things I am not sure at first sight (only by looking at the setup and the module init file):

  • What coding standard is used? The contribution guide does not say anything about it and I get a huge amount of PEP 8 warnings when just opening the setup file.

Looks like I never wrote this up. I don't think I have a problem with anything in Pep8, so we can move toward that standard. If I recall correctly, I wasn't consistent with camelCaps vs. underscore_names. I'm guessing moving to python3 and gtk3 will involve a lot of massive grepping/find-replace, etc. through the entirety of the codebase. If you're taking that on already, it wouldn't be a bad time to also make sure that function names are all done with underscores and attributes are all camelCase.

  • It seems like simple imports like import version instead of from gourmet import version are used. This should be fine if I set the root to the gourmet module itself, but shouldn't it be better to use the second version?

Yes, well early on I don't think there was even necessarily a toplevel gourmet import done anywhere, so nothing was written with the from gourmet style. I am a strong believer in never using import *, but otherwise, I'm pretty neutral. I guess the one thing I find a little frustrating is that if you are running a test on a module or a component, the local imports work better than the absolute imports. But it looks like pep8 recommends strongly against ever just using relative imports, so I assume there's a decent workaround and no real harm to changing from

import gtkextras to import gourmet.gtkextras as gtkextras or from gourmet import gtkextras

(is there a reason to prefer one of the above?)

Additionally, the psyco module is deprecated, see http://psyco.sourceforge.net/, so we should probably have a look at alternative JIT compilers (or drop this feature completely).

Don't think this is a big deal to remove if I recall correctly.

Tom

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-367700391, or mute the thread https://github.com/notifications/unsubscribe-auth/AAi8W_jNMl2pe98yLo9QM4CRoRsG_Cueks5tXXvUgaJpZM4R4cMI .

dyoung418 commented 6 years ago

I'm happy to collaborate on some of these efforts. My time availability is limited, but will do what I can. Things like refactoring for pep8 or Python3 are efforts I can contribute to -- taking time to rethink a module is probably not something I have time for.

rhs-github commented 6 years ago

Reply to @thinkle . I'm not sure I follow. Do you mean language agnostic? Bad choice of words. I really mean to address things things like "pyglet" which imho describes itself perfectly. I walked the ladder back to the ancient 'dll' that is called to I guess eek out a 10 second sound on windows. It is not even in the FreeBSD distro cause it fails miserably. Mostly I'm talking about dependencies. Most people probably do not know that they can start multiple instances of the timer and use different sounds for each. Not all mind you but I bet most. The only thing more dated than gourmet is definitely pyglet. There's no QT in this project. It is definitely a gtk project. Glad you asked>>>Follow this path: /usr/local/lib/python2.7/site-packages/gourmet/plugins/duplicate_finder/recipeMerger.ui File 'recipieMerger.ui' in my project tree has a really nice QT icon pasted on it??? Is this my bad association? My box # freebsd-version -ku 11.1-RELEASE-p4 11.1-RELEASE-p6. It's way down at the bottom of the gourmet ladder and I'm not even half way there yet. Not sure what you imagine. Generally there are some packagers needed on different distros and OSs, but that's it. The pyglet thing is the best example at this point. Since you know that I use FreeBSD and can get any file to play using 'aucat' a 40k completley native (part of base) executable. Most bsd users know this and it's common knowledge. It's directly callable using python. That's my point. Or if you want to expand your horizons and gtk3 bindings are a pain maybe that needs to go as well. Just a thought. Take a look at my draft roadmap - it's more about moving to the cloud than just supporting mobile. Link please. You are the leader! Sorry. I'm really busy at the moment, house, taxes, family, cooking, you know the story. I can't wait to get started. Updating, merging, and managing a repository is not my thing. If you want code or debug, I can go there.

thinkle commented 6 years ago

On Fri, Feb 23, 2018 at 8:14 AM, rhs-github notifications@github.com wrote:

Reply to @thinkle https://github.com/thinkle . I'm not sure I follow. Do you mean language agnostic? Bad choice of words. I really mean to address things things like "pyglet" which imho describes itself perfectly. I walked the ladder back to the ancient 'dll' that is called to I guess eek out a 10 second sound on windows. It is not even in the FreeBSD distro cause it fails miserably. Mostly I'm talking about dependencies. Most people probably do not know that they can start multiple instances of the timer and use different sounds for each. Not all mind you but I bet most. The only thing more dated than gourmet is definitely pyglet.

Ah -- dependencies. Well, it depends on your philosophy. When I first started Gourmet, I rolled my own ORM because SQLObject and SQLAlchemy didn't exist yet. What I had was functional, but a few years down the line people reasonably asked why I wasn't using a well-supported library as the solution, so I made the switch. So that introduces a dependency, yes, but it also makes the code easier for others to hack on. Of course, in that particular case, it also leads to some of the more confusing code, because in Gourmet you can still trace back the archeology of the code (I began with a DB called metakit, then made my own SQL library to fill in for metakit when I ran into performance limitations, then replaced with SQLAlchemy -- all of this helps explain why the DB code is less straightforward than you would expect SQLAlchemy code to be). Point being, as a rule I'd much rather depend on a good outside library than re-implement things from scratch. I think we've had sound-on-windows bugs for a while which may trace back to the pyglet thing you were complaining about -- if you have an easy way to do cross-platform sound on python, by all means please submit a patch :)

There's no QT in this project. It is definitely a gtk project. Glad you asked>>>Follow this path: /usr/local/lib/python2.7/site-packages/gourmet/plugins/ duplicate_finder/recipeMerger.ui File 'recipieMerger.ui' in my project tree has a really nice QT icon pasted on it??? Is this my bad association? My box # freebsd-version -ku 11.1-RELEASE-p4 11.1-RELEASE-p6. It's way down at the bottom of the gourmet ladder and I'm not even half way there yet.

The .ui files are for gtk layouts. It's an XML file format for describing UI.

Not sure what you imagine. Generally there are some packagers needed on different distros and OSs, but that's it. The pyglet thing is the best example at this point. Since you know that I use FreeBSD and can get any file to play using 'aucat' a 40k completley native (part of base) executable. Most bsd users know this and it's common knowledge. It's directly callable using python. That's my point. Or if you want to expand your horizons and gtk3 bindings are a pain maybe that needs to go as well. Just a thought.

Again, feel free to patch sound however you want. Another example of cross-platform PITA is printing: we used to use gnomeprint, which got deprecated. In my opinion the best way to handle printing now is almost certainly to generate PDFs using reportlab (a well-supported well-documented library) and then find a good way to print those. Poppler provided that mechanism, but it's not always supported well on different platforms, so our fallback behavior is to generate a PDF and point the OS to it and hope the OS has a way to print a PDF. Is it great, no? Is there a good cross-platform solution? I don't think so.

Take a look at my draft roadmap - it's more about moving to the cloud than just supporting mobile. Link please. You are the leader! Sorry. I'm really busy at the moment, house, taxes, family, cooking, you know the story. I can't wait to get started. Updating, merging, and managing a repository is not my thing. If you want code or debug, I can go there.

Here's the current brainstorm: https://github.com/thinkle/gourmet/wiki/Gourmet-2.0---Web-Based-Version---Brainstorm

I use Gourmet near daily so I certainly keep it working on my own local machine (I also have some patches locally that I haven't pushed out to the world for various reasons). That said, I don't see much of a future for desktop applications, so until everything breaks, I don't have much motivation to push to gtk3+python3 myself.

When I do hack on a new direction, I'm looking at the "2.0" ideas I flushed out in the brainstorm, but those ideas will likely require basically an entire rewrite, which I may or may not have in me. As you've noticed, there's a lot of code and a lot of features in Gourmet -- everything from nicely handling different encodings to flexible importers and so on -- it would be pretty hard to port all of that into a new system.

One question I have going forward is what kind of community we could build around a new system and how much language matters to that. If I build a new system with a python backend and a javascript front-end, for instance, then building a new plugin that effects the backend would likely require coding in both whatever JS framework we end up with (React, Vue, etc.) and then a python backend. I'm wondering if that barrier to entry ends up being too high. That said, the vast majority of code here is my own anyway, so maybe I shouldn't worry so much about barrier to entry and just do what I think is fun...

Tom

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-368005755, or mute the thread https://github.com/notifications/unsubscribe-auth/AAi8W0U5HeE0EEIFUFVuKl-aHFaAION2ks5tXrmlgaJpZM4R4cMI .

allenerenee commented 6 years ago

I recognize that I am just one user, but once again I am going to plead with you -not- to ditch the desktop version. That it is not in the cloud or a web app is one of Gourmet's primary virtues for me, and I suspect I'm not alone.

On February 23, 2018 10:43:49 AM EST, Tom Hinkle notifications@github.com wrote:

On Fri, Feb 23, 2018 at 8:14 AM, rhs-github notifications@github.com wrote:

Reply to @thinkle https://github.com/thinkle . I'm not sure I follow. Do you mean language agnostic? Bad choice of words. I really mean to address things things like "pyglet" which imho describes itself perfectly. I walked the ladder back to the ancient 'dll' that is called to I guess eek out a 10 second sound on windows. It is not even in the FreeBSD distro cause it fails miserably. Mostly I'm talking about dependencies. Most people probably do not know that they can start multiple instances of the timer and use different sounds for each. Not all mind you but I bet most. The only thing more dated than gourmet is definitely pyglet.

Ah -- dependencies. Well, it depends on your philosophy. When I first started Gourmet, I rolled my own ORM because SQLObject and SQLAlchemy didn't exist yet. What I had was functional, but a few years down the line people reasonably asked why I wasn't using a well-supported library as the solution, so I made the switch. So that introduces a dependency, yes, but it also makes the code easier for others to hack on. Of course, in that particular case, it also leads to some of the more confusing code, because in Gourmet you can still trace back the archeology of the code (I began with a DB called metakit, then made my own SQL library to fill in for metakit when I ran into performance limitations, then replaced with SQLAlchemy -- all of this helps explain why the DB code is less straightforward than you would expect SQLAlchemy code to be). Point being, as a rule I'd much rather depend on a good outside library than re-implement things from scratch. I think we've had sound-on-windows bugs for a while which may trace back to the pyglet thing you were complaining about -- if you have an easy way to do cross-platform sound on python, by all means please submit a patch :)

There's no QT in this project. It is definitely a gtk project. Glad you asked>>>Follow this path: /usr/local/lib/python2.7/site-packages/gourmet/plugins/ duplicate_finder/recipeMerger.ui File 'recipieMerger.ui' in my project tree has a really nice QT icon pasted on it??? Is this my bad association? My box # freebsd-version -ku 11.1-RELEASE-p4 11.1-RELEASE-p6. It's way down at the bottom of the gourmet ladder and I'm not even half way there yet.

The .ui files are for gtk layouts. It's an XML file format for describing UI.

Not sure what you imagine. Generally there are some packagers needed on different distros and OSs, but that's it. The pyglet thing is the best example at this point. Since you know that I use FreeBSD and can get any file to play using 'aucat' a 40k completley native (part of base) executable. Most bsd users know this and it's common knowledge. It's directly callable using python. That's my point. Or if you want to expand your horizons and gtk3 bindings are a pain maybe that needs to go as well. Just a thought.

Again, feel free to patch sound however you want. Another example of cross-platform PITA is printing: we used to use gnomeprint, which got deprecated. In my opinion the best way to handle printing now is almost certainly to generate PDFs using reportlab (a well-supported well-documented library) and then find a good way to print those. Poppler provided that mechanism, but it's not always supported well on different platforms, so our fallback behavior is to generate a PDF and point the OS to it and hope the OS has a way to print a PDF. Is it great, no? Is there a good cross-platform solution? I don't think so.

Take a look at my draft roadmap - it's more about moving to the cloud than just supporting mobile. Link please. You are the leader! Sorry. I'm really busy at the moment, house, taxes, family, cooking, you know the story. I can't wait to get started. Updating, merging, and managing a repository is not my thing. If you want code or debug, I can go there.

Here's the current brainstorm: https://github.com/thinkle/gourmet/wiki/Gourmet-2.0---Web-Based-Version---Brainstorm

I use Gourmet near daily so I certainly keep it working on my own local machine (I also have some patches locally that I haven't pushed out to the world for various reasons). That said, I don't see much of a future for desktop applications, so until everything breaks, I don't have much motivation to push to gtk3+python3 myself.

When I do hack on a new direction, I'm looking at the "2.0" ideas I flushed out in the brainstorm, but those ideas will likely require basically an entire rewrite, which I may or may not have in me. As you've noticed, there's a lot of code and a lot of features in Gourmet -- everything from nicely handling different encodings to flexible importers and so on -- it would be pretty hard to port all of that into a new system.

One question I have going forward is what kind of community we could build around a new system and how much language matters to that. If I build a new system with a python backend and a javascript front-end, for instance, then building a new plugin that effects the backend would likely require coding in both whatever JS framework we end up with (React, Vue, etc.) and then a python backend. I'm wondering if that barrier to entry ends up being too high. That said, the vast majority of code here is my own anyway, so maybe I shouldn't worry so much about barrier to entry and just do what I think is fun...

Tom

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/thinkle/gourmet/issues/897#issuecomment-368005755, or mute the thread

https://github.com/notifications/unsubscribe-auth/AAi8W0U5HeE0EEIFUFVuKl-aHFaAION2ks5tXrmlgaJpZM4R4cMI .

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/thinkle/gourmet/issues/897#issuecomment-368045705

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

MarkP2015 commented 6 years ago

Mr. allenerenee

and I are in agreement. I would not be able to use a mobile device for my cookbook work.

From: allenerenee notifications@github.com Sent: Saturday, February 24, 2018 8:07:51 AM To: thinkle/gourmet Cc: Subscribed Subject: Re: [thinkle/gourmet] Call for more Gourmet developers and maintainers (#897)

I recognize that I am just one user, but once again I am going to plead with you -not- to ditch the desktop version. That it is not in the cloud or a web app is one of Gourmet's primary virtues for me, and I suspect I'm not alone.

On February 23, 2018 10:43:49 AM EST, Tom Hinkle notifications@github.com wrote:

On Fri, Feb 23, 2018 at 8:14 AM, rhs-github notifications@github.com wrote:

Reply to @thinkle https://github.com/thinkle . I'm not sure I follow. Do you mean language agnostic? Bad choice of words. I really mean to address things things like "pyglet" which imho describes itself perfectly. I walked the ladder back to the ancient 'dll' that is called to I guess eek out a 10 second sound on windows. It is not even in the FreeBSD distro cause it fails miserably. Mostly I'm talking about dependencies. Most people probably do not know that they can start multiple instances of the timer and use different sounds for each. Not all mind you but I bet most. The only thing more dated than gourmet is definitely pyglet.

Ah -- dependencies. Well, it depends on your philosophy. When I first started Gourmet, I rolled my own ORM because SQLObject and SQLAlchemy didn't exist yet. What I had was functional, but a few years down the line people reasonably asked why I wasn't using a well-supported library as the solution, so I made the switch. So that introduces a dependency, yes, but it also makes the code easier for others to hack on. Of course, in that particular case, it also leads to some of the more confusing code, because in Gourmet you can still trace back the archeology of the code (I began with a DB called metakit, then made my own SQL library to fill in for metakit when I ran into performance limitations, then replaced with SQLAlchemy -- all of this helps explain why the DB code is less straightforward than you would expect SQLAlchemy code to be). Point being, as a rule I'd much rather depend on a good outside library than re-implement things from scratch. I think we've had sound-on-windows bugs for a while which may trace back to the pyglet thing you were complaining about -- if you have an easy way to do cross-platform sound on python, by all means please submit a patch :)

There's no QT in this project. It is definitely a gtk project. Glad you asked>>>Follow this path: /usr/local/lib/python2.7/site-packages/gourmet/plugins/ duplicate_finder/recipeMerger.ui File 'recipieMerger.ui' in my project tree has a really nice QT icon pasted on it??? Is this my bad association? My box # freebsd-version -ku 11.1-RELEASE-p4 11.1-RELEASE-p6. It's way down at the bottom of the gourmet ladder and I'm not even half way there yet.

The .ui files are for gtk layouts. It's an XML file format for describing UI.

Not sure what you imagine. Generally there are some packagers needed on different distros and OSs, but that's it. The pyglet thing is the best example at this point. Since you know that I use FreeBSD and can get any file to play using 'aucat' a 40k completley native (part of base) executable. Most bsd users know this and it's common knowledge. It's directly callable using python. That's my point. Or if you want to expand your horizons and gtk3 bindings are a pain maybe that needs to go as well. Just a thought.

Again, feel free to patch sound however you want. Another example of cross-platform PITA is printing: we used to use gnomeprint, which got deprecated. In my opinion the best way to handle printing now is almost certainly to generate PDFs using reportlab (a well-supported well-documented library) and then find a good way to print those. Poppler provided that mechanism, but it's not always supported well on different platforms, so our fallback behavior is to generate a PDF and point the OS to it and hope the OS has a way to print a PDF. Is it great, no? Is there a good cross-platform solution? I don't think so.

Take a look at my draft roadmap - it's more about moving to the cloud than just supporting mobile. Link please. You are the leader! Sorry. I'm really busy at the moment, house, taxes, family, cooking, you know the story. I can't wait to get started. Updating, merging, and managing a repository is not my thing. If you want code or debug, I can go there.

Here's the current brainstorm: https://github.com/thinkle/gourmet/wiki/Gourmet-2.0---Web-Based-Version---Brainstorm

I use Gourmet near daily so I certainly keep it working on my own local machine (I also have some patches locally that I haven't pushed out to the world for various reasons). That said, I don't see much of a future for desktop applications, so until everything breaks, I don't have much motivation to push to gtk3+python3 myself.

When I do hack on a new direction, I'm looking at the "2.0" ideas I flushed out in the brainstorm, but those ideas will likely require basically an entire rewrite, which I may or may not have in me. As you've noticed, there's a lot of code and a lot of features in Gourmet -- everything from nicely handling different encodings to flexible importers and so on -- it would be pretty hard to port all of that into a new system.

One question I have going forward is what kind of community we could build around a new system and how much language matters to that. If I build a new system with a python backend and a javascript front-end, for instance, then building a new plugin that effects the backend would likely require coding in both whatever JS framework we end up with (React, Vue, etc.) and then a python backend. I'm wondering if that barrier to entry ends up being too high. That said, the vast majority of code here is my own anyway, so maybe I shouldn't worry so much about barrier to entry and just do what I think is fun...

Tom

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/thinkle/gourmet/issues/897#issuecomment-368005755, or mute the thread

https://github.com/notifications/unsubscribe-auth/AAi8W0U5HeE0EEIFUFVuKl-aHFaAION2ks5tXrmlgaJpZM4R4cMI .

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/thinkle/gourmet/issues/897#issuecomment-368045705

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/thinkle/gourmet/issues/897#issuecomment-368238611, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AO-pPmQHz3Mrl2p0ciFQP3tzDNT7Ugu-ks5tYDPXgaJpZM4R4cMI.

micahcochran commented 6 years ago

@thinkle Once you have laid all of this out, I think that you are on exactly the right path. I believe in your vision. Perhaps the only thing is that you are trying to make an application that uses HTML and a browser, but not trying to go to the extent of making a publicly available website (with all the security and scale required for that). This would be software that will run on your machine and if you poke a hole in your firewall, it will work on your home network.

I don't see that there is whole lot of difference between a desktop version and a browser version. If a browser works on your machine, python, and whatever extension are need, then it will work. Heck, you could even install an Gourmet icon that launches the python end and your web browser.

holocronweaver commented 6 years ago

We can have both web apps and native apps!

They can all be different apps that communicate with the same underlying server backend. That is the beauty of the client-server model. One service, many app choices.

Everyone gets what they want, everyone wins. :smile:

More on client-server models for the curious

Music and video streaming, cloud storage, torrent clients, e-mail clients, social media clients, etc. all use client-server models. Most people would use native apps for those on their mobile device (not a web app!), while they may choose either a web app or native app on their desktop depending on personal preference and options available.

This is especially beneficial for open source because it lets the core developers focus on the server backend and maybe one or two flagship clients (maybe a web and/or desktop app?), while other developers are free to create whatever clients they want to fill in gaps (Android and iOS apps, desktop apps, VR apps, whatever!). It also means new features can be implemented in the server and all clients benefit. Further, it opens up possibilities like one client being able to connect to many services (e.g., Twidere), or a client adding additional features the server doesn't have (e.g., torrent search in torrent clients, perhaps recipe search in Gourmet's case).

There are some difficulties with an open client-server model, namely the server API must be carefully defined, clients need updating to make use of new server features, developers are needed to maintain all the clients, and sometimes clients outgrow their service and give birth to a fork or entirely new service, but I know of no better option at present. The dream of a single UI to rule them all has not yet come to pass, and I don't suspect it will for at least another decade.

thinkle commented 6 years ago

Hey all,

I've spent a couple of days hacking on a React proof-of-concept for Gourmet 2.0 -- well, more learning than hacking, but also hacking. I appreciate the involvement and energy in this thread and thought it might be helpful to give an update in case anyone has relevant experience and is interested in joining in the early work.

Here's what I've got built so far:

  1. a "view" layer in React. I started a React Native version originally, but since I'm (A) more familiar with web development (B) more interested in getting a in-the-browser desktop-app replacement off the ground first, I switched over to vanilla react and a web version for now. That said, the whole advantage of using React is that the React Native platform is there to make Android/iOS versions reasonably quick to spin up. My goal is to keep as much logic in the controller as possible, so that the code that has to be customized to the web vs. Android vs. iOS is minimal.

  2. I have a "controller" layer using mobx as a store to handle fetching recipes, etc. This would be a layer that would be shared between different front-end code and would handle communication with the backend.

  3. a "db" layer in CouchDB. I've just barely started playing with this and I'll want to do some tests to see how well CouchDB performs, but it looks to me like CouchDB + PouchDB is built to support just the kind of syncing I'm imagining, and opens up some nice possibilities for syncing recipes between different locations (cloud & local storage). It's also possible that CouchDB can basically act as a backend on its own, making obsolete/unnecessary much of the server-side code I was initially imagining creating (rather than having to define a clear API, we'd basically have to define a clear structure for the DB and then the CouchDB API is our API).

I'd like to get code a little bit cleaner before pushing a repo up to the web (and when I do so I'm not sure where it should live anyway), but I wanted to share what I'm up to in case anyone listening on this thread already has significant experience with any of these technologies (React, Mobx, CouchDB).

I'm not yet wedded to any of the choices; in each case, I've done a fair amount of research before settling on the choice but I'd be happy to hear from folks who have opinions on the technologies. For example, I actually much prefer Vue and I have more experience working with Vue on other projects, but the Vue->Mobile choices just aren't as well documented (Weex is out there and backed by Alibaba, but if you don't speak Chinese, the docs are not so good) and I ended up getting further building my hello-world in React, so that's where I'm heading for now.

For the store, I also played with Redux, which seems like the most widely supported store for React, but I found it was way too heavy on boilerplate for my preferences. When I found mobx, it seemed like I could write much cleaner code (and using classes, decorators & other ES6 features feels very pythonic and familiar to me and much cleaner than deep-copying objects left and right for the pure-function approach required by Redux).

Finally, I'm skeptical of moving away from SQL, but it does seem like recipes really are very much like documents, so Gourmet might be an ideal usecase for a NoSQL approach. Furthermore, CouchDB seems to be really built for the kind of syncing that I'm imagining being instrumental to a future Gourmet that lives partly in the cloud, partly on devices. My next step is going to be exporting a large DB of recipes into Couch so I can start playing with queries and doing some performance testing, as well as getting used to the CouchDB way of handling queries and making sure it's workable for our use case. As I do so, I might end up creating a migration tool in the mean time, which would give existing Gourmet users a path to push their data to the new platform.

If folks want to be involved, I'm happy to start sharing code sooner rather than later. That said, I wouldn't be shocked if most folks on this thread don't feel super comfortable on javascript and aren't about to jump in, in which case I'll wait until I have a stabler codebase before pushing to github.

A final note, it also would be theoretically possible to add a CouchDB backend to the existing Gourmet codebase to enable the desktop app to be interoperable with the new code, but my guess is this won't be a worthwhile endeavor...

Cheers, Tom

On Sat, Feb 24, 2018 at 5:47 PM, Jesse Johnson notifications@github.com wrote:

We can have both web apps and native apps!

They can all be different apps that communicate with the same underlying server backend. That is the beauty of the client-server model. One service, many app choices.

Everyone gets what they want, everyone wins. 😄 More on client-server models for the curious

Music and video streaming, cloud storage, torrent clients, e-mail clients, social media clients, etc. all use client-server models. Most people would use native apps for those on their mobile device (not a web app!), while they may choose either a web app or native app on their desktop depending on personal preference and options available.

This is especially beneficial for open source because it lets the core developers focus on the server backend and maybe one or two flagship clients (maybe a web and/or desktop app?), while other developers are free to create whatever clients they want to fill in gaps (Android and iOS apps, desktop apps, VR apps, whatever!). It also means new features can be implemented in the server and all clients benefit. Further, it opens up possibilities like one client being able to connect to many services (e.g., Twidere), or a client adding additional features the server doesn't have (e.g., torrent search in torrent clients, perhaps recipe search in Gourmet's case).

There are some difficulties with an open client-server model, namely the server API must be carefully defined, clients need updating to make use of new server features, developers are needed to maintain all the clients, and sometimes clients outgrow their service and give birth to a fork or entirely new service, but I know of no better option at present. The dream of a single UI to rule them all has not yet come to pass, and I don't suspect it will for at least another decade.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-368266431, or mute the thread https://github.com/notifications/unsubscribe-auth/AAi8W8EH0XXLrHCwdwTHUHQxKvJI0mSwks5tYJGYgaJpZM4R4cMI .

FriedrichFroebel commented 6 years ago

Looks like I never wrote this up. I don't think I have a problem with anything in Pep8, so we can move toward that standard. If I recall correctly, I wasn't consistent with camelCaps vs. underscore_names. I'm guessing moving to python3 and gtk3 will involve a lot of massive grepping/find-replace, etc. through the entirety of the codebase. If you're taking that on already, it wouldn't be a bad time to also make sure that function names are all done with underscores and attributes are all camelCase.

Seems like there is another coding guide besides the contribution guide I did not see the link for. The coding guide recommends PEP8.

(is there a reason to prefer one of the above?)

I think it is much cleaner and easier to understand where this import is coming from when using this way.

FriedrichFroebel commented 6 years ago

I just took some time starting to port the application to Python3 and GTK3. With the short look at the code before, it seemed like this just would be a task involving some time. Now, after having ported some files, I am not really sure whether the amount of time to spend for porting or the amount of time to spend for rewriting the application from scratch (based on the existing ideas) would be shorter.

The reason for this is simple: The current code base seems to have grown historically, but - without having looked at the commit history - did not receive any real refactoring. Some of the bigger changes - like the ones tagged with gsoc-idea - do not seem to have received a lot of attention (I know that this is an FOSS project and nobody is forced to spend their free time on it). Refactoring may be blocked by the fact that there are no real automated tests (only a document describing the testing procedure done with the GUI) - inside the source itself there are some (commented) print statements probably used for debugging (besides the normal debugging mechanism), some main entry points for manual tests of individual modules and a database stress tester, but this is not automated, too. To satisfy the requirements of PEP8, we have to touch around half of the code (check done using pycodestyle and cloc). (I am not really a fan of automating this to be able to check everything is still working.) For people which may be not familiar with the code (including me), some documentation may be missing at the moment making it hard to understand and to start with contributing.

Regarding Gourmet 2.0: I am no fan of the client server architecture in this case. While it may be usable for technically adept persons, I do not think the normal users of Gourmet will really need this. PHPRecipeBook already offers some (basic) web frontend for recipe management (although I have not tried it). For this reason a real desktop application like the current one is the best thing in my opinion. In the other issue related to the future of Gourmet, there had already been a proposal of using a normal file sync service to be able to use the local database inside a smartphone application. An alternative would be to create a (pluggable) server backend to use with Gourmet, but using the local SQLite3 database by default (if I remember correctly, there had been a similar proposal in one of the issues). This way there could be native applications as well as applications build upon an API.

holocronweaver commented 6 years ago

@FriedrichFroebel Many desktop apps use client server arch, including games, and you never realize it! That is because a single app can launch both the server and client, hiding all the details from the user. You can even do it all in one process, launching the server and client as separate threads. I mentioned this in the previous thread, as well as why a cloud storage sync solution wouldn't work well on mobile.

MarkP2015 commented 6 years ago

The move to mobile apps is a luxury that those who have monthly cell phone service and a paid recipe manager account may flourish with. For me, a cookbook author (Ti: California Mission Cookery), I like a desktop version. I don't want (although GRM has) shopping lists. If the amount of time Mr. Froebel states is true, let those coders who want fancy please find a way to keep it simple.

For example, I have a recipe for hamburgers for 8 servings. When I asked for a shopping list, up came the Select Optional Ingredients window. I've made a screenshot and attached it here. As I know the recipe is for 8 servings, I can approximate how much lettuce, tomato (slices), pickle (slices) and ketchup, mustard, etc. I'll need for that meal. Asking for code to quantify such may be doable, but it isn't simple. Some cooks may need that much help. I think GRM shouldn't be the solution for them. To me, GRM is about personal use, not professional. By professional I mean institutional kitchens servings dozens to thousands of people daily. Those users of recipe management sofware should be funding this project if they want that powerful a datbase.

Thanks for reading my 2 cents worth.

From: FriedrichFroebel notifications@github.com Sent: Sunday, March 4, 2018 7:37:34 AM To: thinkle/gourmet Cc: MarkP2015; Comment Subject: Re: [thinkle/gourmet] Call for more Gourmet developers and maintainers (#897)

I just took some time starting to port the application to Python3 and GTK3. With the short look at the code before, it seemed like this just would be a task involving some time. Now, after having ported some files, I am not really sure whether the amount of time to spend for porting or the amount of time to spend for rewriting the application from scratch (based on the existing ideas) would be shorter.

The reason for this is simple: The current code base seems to have grown historically, but - without having looked at the commit history - did not receive any real refactoring. Some of the bigger changes - like the ones tagged with gsoc-idea - do not seem to have received a lot of attention (I know that this is an FOSS project and nobody is forced to spend their free time on it). Refactoring may be blocked by the fact that there are no real automated tests (only a document describing the testing procedure done with the GUI) - inside the source itself there are some (commented) print statements probably used for debugging (besides the normal debugging mechanism), some main entry points for manual tests of individual modules and a database stress tester, but this is not automated, too. To satisfy the requirements of PEP8, we have to touch about half of the code (check done using pycodestyle and cloc). For people which may be not familiar with the code (including me), some documentation may be missing at the moment making it hard to understand and to start with contributing. At some places in the code I get warnings about undefined methods and properties from my IDE, but I do not yet know the cause for this. (Maybe this is a result of having only partially ported the existing code, but as this occurs with class-internal objects in ported classes, too, this is not make sense for me).

Regarding Gourmet 2.0: I am no fan of the client server architecture in this case. While it may be usable for technically adept persons, I do not think the normal users of Gourmet will really need this. PHPRecipeBook already offers some (basic) web frontend for recipe management (although I have not tried it). For this reason a real desktop application like the current one is the best thing in my opinion. In the other issue related to the future of Gourmet, there had already been a proposal of using a normal file sync service to be able to use the local database inside a smartphone application. An alternative would be to create a (pluggable) server backend to use with Gourmet, but using the local SQLite3 database by default (if I remember correctly, there had been a similar proposal in one of the issues). This way there could be native applications as well as applications build upon an API.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/thinkle/gourmet/issues/897#issuecomment-370238466, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AO-pPqXOd_hgXYhJP8q64q2VmlmhFWdOks5tbAo-gaJpZM4R4cMI.

FriedrichFroebel commented 6 years ago

@holocronweaver I am aware of this. I did not want to start an in-depth discussion whether client server or native applications are better - instead I only wanted to point out that a normal user probably does not need a CS architecture. Maybe this is partially caused by the fact that I am not a fan of the mass of new web frameworks and prefer native local applications, but this is something different.

holocronweaver commented 6 years ago

@FriedrichFroebel Client-server is a program design paradigm. It can be used in native apps, web apps, or any sort of program. So it is not native app vs. client-server, that is an apples-oranges comparison. Client-server models can (and should) be able to work completely locally on a lone desktop app, even in the absence of any network access. In other words, users currently using Gourmet 2 locally on desktop would not see any difference from Gourmet 1. It would work like Notepad or any other vanilla desktop app. No special configuration needed, and no network access required.

Edit: I think the confusion stems from people associating 'server' with things like Apache HTTP servers and related stacks, which require lots of configuration to set up. That is only one kind of server though, and not the one I have in mind for Gourmet. Instead native apps should internally embed a server, something the user never needs to know about, and which can be used to do everything locally without a network connection.

holocronweaver commented 6 years ago

@thinkle Exciting to hear development on the new project!

I have a few questions:

  1. How would setting up CouchDB for a local-only desktop app work? This should require no user expertise, the app just magically acts like any other desktop app.
  2. If the only server will be a database, that means a common library should be written which front ends can reuse for performing tasks like calculating nutrition information of a recipe from its ingredients, unit conversions, etc. Otherwise every frontend will essentially be a completely independent application, with the only unifying feature being the DB schema. It sort of sounds like you intend mobx to be used as an API library for frontends, but wouldn't that limit all front ends to JS? Or else we would indeed end up in a world with every frontend writes everything from scratch?
  3. In NoSQL, how would we relate recipes to ingredients to nutrition information? That sounds like a relational database to me, but I have only used NoSQL lightly.
  4. It seems like addons would either be frontend specific or have no place in G2. Thoughts on this?

I strongly prefer a solution which is client language agnostic so as not to limit what apps can be written, but also doesn't lead to every client writing their own program from scratch. My ideal solution would involve a shared library and/or server API, possibly splitting the server into remote and local components in order to do as much work as possible on the client. The crumple in this dream is that I know of no way to create a shared client-side library / server that is usable both in native and web apps. Maybe you have some ideas here? Nim looks like it might be able to achieve this, but are there more time tested solutions? I am surprised this is still an issue in 2018...

holocronweaver commented 6 years ago

I am not sure how feasible it is in practice, but there are a few projects which allow running Python in browser frontend. There seem to be two classes of these: one is Python-to-JS transpilers, like Transcrypt, and the other is full-on Python interpreters written in JS, like brython. I would imagine the transpiler would be far more performant. While these aren't ideal solutions, they might help solve the problem of a shared client-side library that can be used both by web and native clients.

thinkle commented 6 years ago

On Sun, Mar 4, 2018 at 1:08 PM, Jesse Johnson notifications@github.com wrote:

@thinkle https://github.com/thinkle Exciting to hear development on the new project!

I have a few questions:

  1. How would setting up CouchDB for a local-only desktop app work? This should require no user expertise, the app just magically acts like any other desktop app.

If someone wanted to write a pure desktop app, I think it would still be doable. One thing I'm still learning about is the relationship between "couchdb" and "pouchdb," but I think the basic idea is that pouchdb can work for local storage. Given that pouchdb could give you offline storage in the browser, it's not clear to me we'd need a desktop app anyway, but it could be workable. The fastest thing from my perspective would be to make a new version of Gourmet's DB that worked with pouchdb -- that would be kind of the bandaid approach -- but obviously that kind of evolution leads to a less-than-clean codebase.

  1. If the only server will be a database, that means a common library should be written which front ends can reuse for performing tasks like calculating nutrition information of a recipe from its ingredients, unit conversions, etc. Otherwise every frontend will essentially be a completely independent application, with the only unifying feature being the DB schema. It sort of sounds like you intend mobx to be used as an API library for frontends, but wouldn't that limit all front ends to JS? Or else we would indeed end up in a world with every frontend writes everything from scratch?

Front-ends would be pretty heavy in this world, but that's how JS apps work too. If you want your app to be responsive, you want a lot of it happening in the front end -- every call to the backend potentially has latency, might break, etc.

What I've been working on thus far is building out a "controller" layer where logic like getting nutritional info would live. That would be a javascript layer thus far, which would support React Native + React Web (it would also support a different framework, so if you want with Vue, for example, it would support both native Vue and Weex Vue on the front end for mobile). The same controller layer could be used in a chrome/firefox plugin to handle recipe import. In all of these cases, javascript seems like a really convenient choice.

  1. In NoSQL, how would we relate recipes to ingredients to nutrition information? That sounds like a relational database to me, but I have only used NoSQL lightly.

That is most definitely relational. We're not going to be storing all the nutritional info with each recipe, so at the end of the day we'll be storing pointers to a separate nutritional table, which is how relational DBs work as well. The question is where to store those pointers.

In Gourmet currently, this requires 3 layers:

  1. Ingredient Table -> Ingredient Item - Ingredient Key - etc.
  2. Nutritional Table -> ID -> Nutritional Info
  3. Ingkey Lookup -> Ingredient Key -> Nutritional Key

One problem with this is that it assumes each ingredient key always points to the same nutritional information. If the databases begin to become "shared," that starts to be a problem because, for instance, in my Gourmet I have "milk" point to "milk, skim" since that's what we usually have at my house, but another user will want to point to 2% and another to whole. Those are different decisions for different people.

My first thought for a solution here is...

  1. The ingredients contained in the recipe object can contain pointers directly to one or possibly more nutritional IDs (we could potentially support the ability for something like what's below, though this starts introducing a level of complexity I might rather avoid:

    ingredients : [ {name : 'milk', nutritional_links : [ {type:'approximate', target: '1a29d3812z3', density:0.879}, {type:'user', users:['thinkle'], target:'1a09829823',density:0.879} ]}

  2. The controller contains helper methods for guessing/looking up nutritional information when its absent and possibly populating the object with the results (with user confirmation etc).

It's possible we'd need additional lookup tables (or new views, in Couch parlance) as part of the process, but I think those are basically implementation details.

  1. It seems like addons would either be frontend specific or have no place in G2. Thoughts on this?

I strongly prefer a solution which is client language agnostic so as not to limit what apps can be written, but also doesn't lead to every client writing their own program from scratch. My ideal solution would involve a shared library and/or server API, possibly splitting the server into remote and local components in order to do as much work as possible on the client. The crumple in this dream is that I know of no way to create a shared client-side library / server that is usable both in native and web apps. Maybe you have some ideas here? Nim https://nim-lang.org/ looks like it might be able to achieve this, but are there more time tested solutions? I am surprised this is still an issue in 2018...

Well, lots of APIs exist out there, right? Usually at the end of the day they use HTTP to communicate (as does Couch) and then people write language bindings as needed. That's why I'm saying CouchDB basically could be the API in large part.

But in large part we need an actual use case where we'd need these other language bindings. So far, I'm imagining three different "front ends" -- a browser extension, a mobile app, and a web app. All of them can work with javascript as the primary language (the web and the browser extension have to use JS -- the mobile apps would have to split to Java & C# or whatever apple's doing these days if we went native, or could use React Native or another JS->native solution). Point being, as of right now, the case for JS looks awfully compelling.

Tom

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-370249983, or mute the thread https://github.com/notifications/unsubscribe-auth/AAi8W2-tvHdF51YHa040dHyGyco49-t6ks5tbC2UgaJpZM4R4cMI .

freeagent1384 commented 6 years ago

Only because I was trying some new recipes which didn't import did I check out the page and see the call for programmers. I'm not well accomplished but would like to help as much as I can. That being said, looking through the comments here it sounds like you're looking to move away from Python and into more Java/JS and I have very little experience with those languages. If you decide to stick with Python please let me know, I would love to help.

That being said if I may offer my two cents on the server-client preference. I run Gourmet on all my machines, both Linux and Windows and I just sync my database with a symlink to an encrypted file in my DropBox folder. I would love to see the ability to have this file syncing built in to the app but really not a big deal. The idea however of putting my recipes anywhere other than storage of my own control is exactly why I chose Gourmet to begin with. As long as the Server portion can be run locally on my own machine, even if it were in a Docker container I find much more appealing.

I wish I had more to offer if you decide to traverse the path of webapp, it's probably something I should be learning anyhow but if you decide to stick with Python please, hit me up.

benjaminogles commented 6 years ago

Out of my own need and boredom I hacked on my own recipe manager for a little while before coming across Gourmet. After seeing this project I think I like the idea of contributing here better than doing everything myself.

You can checkout what I have built at https://pantrybudget.com It is a lot like Gourmet. Import recipes from other sites, make grocery lists etc. I also have a menu planning feature and the ability to save price data for common ingredients.

I had a lot of ideas I wanted to get implemented but like I said, I think it would be better to collaborate on a project like this to get things done faster.

I built mine with React and Relay and a Graphcool backend. I'm no stranger to python either so I will be checking in to see where I can help out with the new Gourmet. Let me know if you have questions about picking a web framework since I have worked with a few. I must say that I am partial to desktop clients though :)

shahafalo commented 6 years ago

I would like to help to develop in python 2 for thus project :)

jcrben commented 6 years ago

@benjaminogles as you might have noticed above @thinkle would prefer something with web technology (as would I) - any interest in open-sourcing your project? that's something I might be willing to pitch in and help with

the other two open-source recipe apps I encountered:

saxon-s commented 6 years ago

I'm jumping into this thread late ...

@holocronweaver thank you for taking the lead in calling for more Gourmet developers and maintainers. It is appreciated. Like you I enjoy using Gourmet and would love to see it get the proper attention to help keep it alive and relevant.

Your request has sparked off a good debate. There appears to be 2 camps -- those who want to maintain a stand alone app and those who want to develop a new web application.

Let me say upfront that I'm in favour of maintaining the existing stand alone GTK Gourmet application until such time there is a stable replacement and and compelling reason to switch.

Yes it is exciting to start something new, but be fully aware of what you are getting into ... take a read of the article "How it feels to learn JavaScript in 2016": https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f Even though the article was written 2 years ago and written tongue-in-cheek, it is still relevant and has a thread of truth to it. There are a forever changing sea of new JS web technologies ... coffee script, typescript, Vue, Backbone, React, Angular, Ember - all of which have their own cult followers and popularity trends which tend to come and go just as quick. Then there are browser compatibility issues ... chrome/chromium, IE, Edge, Firefox, safari and mobile iOS and Android platforms - each performing and displaying content slightly differently. Let's not forget about maintenance ... If it was difficult maintaining a stand alone GTK application with the existing Gourmet community - web technology is not going to make it any easier (in fact it will be the opposite. For one, a proper automated test suite is an absolute must). I'm not trying to resist the development of a new web application or dampen the enthusiasm but rather give a dose of reality in what it takes to develop and maintain a web application. The question to ask is ... do we have the skills and commitment in the Gourmet community to fully support a web based app? If yes, then go for it!

Gourmet Maintenance I'm willing to help maintain the existing Gourmet application. Over the weekend I submitted a new pull request #910 to fix the ./bin/gourmet launch issue and broken plugin and doc_dir paths. I updated issue #867 with details of the fixes I submitted.

There are a couple of areas that need to be tackeled:

SQLAlchemy ORM and Python3/GTK are XL developments needs to done on separate branches.

PEP8 Support @rhs-github @dyoung418 @FriedrichFroebel While I agree that we should be adhering to PEP8 I'm not in favour of doing a pep8 storming of the entire project as it has a couple negative side effects:

Instead, only new or modified code should be updated to pep8. pep8radius (https://pypi.org/project/pep8radius/) is a utility which updates only those lines which you have been working on since the last commit/branch to comply to pep8. Only once the Gourmet code base has been stabilized, updated, tagged and released should pep8 storming of the entire project be considered.

Andy Hayden, the author of pep8radius summarizes it's usage as - Basically leaving the project a little better than you found it.

Installation: pip install pep8radius

Usage: Suppose you've done your work off of master and are ready to commit:

# be somewhere in your project directory
# see the diff with pep, see the changes you've made since master
pep8radius master --diff
# make those changes
pep8radius master --diff --in-place

Or to clean the new lines you've commited since the last commit:

pep8radius --diff
pep8radius --diff --in-place
# the lines which changed since a specific commit `git diff 98f51f`
pep8radius 98f51f --diff

Next Steps The next steps depend on if we get sufficient support from our Gourmet development community and repo admin support. Without either of them this initiative is a no go.

davpaez commented 6 years ago

Hi everyone. I completely agree with @saxon-s . I'm excited by the new client-server idea, but I think Gourmet 1 should not be abandoned.

Please let me know if I can help with the current version of gourmet. I'm a beginner python developer but I've already build a couple of gui apps in python using pyqt. I think I may be able to contribute.

maphew commented 4 years ago

A couple projects that might be useful:

pyodide - a mozilla project to bring a full python science stack to the browser, opening a path that doesn't entail a total rewrite.

flexx - a toolkit for creating GUIs using web technology for rendering. Apps are pure Python; The PScript transpiler generates the necessary JavaScript on the fly. Create cross platform desktop applications, web applications, and exported apps as standalone HTML documents.

chiffa commented 4 years ago

Hey @saxon-s - looks like you are by now the only maintainer.

Given that I like and use Gourmet myself and have seen a couple of issues with it, I would be glad to jump on the train of making it work better.

Given the size of the project, however, I would need a rapid walk-through the code.

Do you have any channel developers here use (Discord, Slack, IRC channel?)

thinkle commented 4 years ago

All -- for what it's worth, I've been in the midst of a several week sprint on a web version and am pretty close to a proof of concept. It is a whole different skill set, of course, but I've built up a fair amount of web skills in other work in the past few years. The biggest challenge of course is it's a totally different distribution model -- there's no simple way to just download and run your own web app...

Tom

On Sun, May 31, 2020 at 12:10 PM Andrei Kucharavy notifications@github.com wrote:

Hey @saxon-s https://github.com/saxon-s - looks like you are by now the only maintainer.

Given that I like and use Gourmet myself and have seen a couple of issues with it, I would be glad to jump on the train of making it work better.

Given the size of the project, however, I would need a rapid walk-through the code.

Do you have any channel developers here use (Discord, Slack, IRC channel?)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-636491793, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELYWY4WBGUK7IU3GJCC5TRUJ6PLANCNFSM4EPBYMEA .

chiffa commented 4 years ago

@thinkle - thanks for the heads-up.

Does it mean that the current Python-based version is planned to be phased out at some point?

thinkle commented 4 years ago

Andrei -- I don't have any plans to eliminate it, but I wasn't willing to put the work in for the python 3 transition. That said, there's a crew working on that transition now, so the python version should keep living. Except for the fact that I wrote them, the codebases are pretty much entirely separate. I wrote a little tool to export my recipes to a new format which I might translate into the python version so existing users can migrate, but I don't see any reason people who are happy w/ the desktop version can't keep using it.

Tom

On Sun, May 31, 2020 at 4:30 PM Andrei Kucharavy notifications@github.com wrote:

@thinkle https://github.com/thinkle - thanks for the heads-up.

Does it mean that the current Python-based version is planned to be phased out at some point?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thinkle/gourmet/issues/897#issuecomment-636525265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAELYW7LQN37JNWDJJGBSX3RUK44ZANCNFSM4EPBYMEA .