Call for more Gourmet developers and maintainers #897
Comments
|
I can help get |
|
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. |
|
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, 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. |
holocronweaver
changed the title
|
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? |
|
Hi @rhs-github. I am not sure what your question is. Are you asking how to submit a pull request? |
|
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: Take me to your leader! |
|
On Wed, Feb 21, 2018, 12:50 PM rhs-github ***@***.***> 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
<#897 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAi8W8fc65SkUHhKcR1IN3ac1TSOKrCHks5tXFdmgaJpZM4R4cMI>
.
|
|
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 |
|
On Thu, Feb 22, 2018 at 9:38 AM, FriedrichFroebel ***@***.***> 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
<#897 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAi8W_jNMl2pe98yLo9QM4CRoRsG_Cueks5tXXvUgaJpZM4R4cMI>
.
|
|
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. |
|
Reply to @thinkle . |
|
On Fri, Feb 23, 2018 at 8:14 AM, rhs-github ***@***.***> 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
<#897 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAi8W0U5HeE0EEIFUFVuKl-aHFaAION2ks5tXrmlgaJpZM4R4cMI>
.
|
|
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 ***@***.***> wrote:
On Fri, Feb 23, 2018 at 8:14 AM, rhs-github ***@***.***>
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
>
<#897 (comment)>,
> 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:
#897 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
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 ***@***.***> wrote:
On Fri, Feb 23, 2018 at 8:14 AM, rhs-github ***@***.***>
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
>
<#897 (comment)>,
> 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:
#897 (comment)
--
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 GitHub<#897 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AO-pPmQHz3Mrl2p0ciFQP3tzDNT7Ugu-ks5tYDPXgaJpZM4R4cMI>.
|
|
@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. |
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 curiousMusic 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. |
|
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 ***@***.***> 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
<#897 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAi8W8EH0XXLrHCwdwTHUHQxKvJI0mSwks5tYJGYgaJpZM4R4cMI>
.
|
Seems like there is another coding guide besides the contribution guide I did not see the link for. The coding guide recommends PEP8.
I think it is much cleaner and easier to understand where this import is coming from when using this way. |
|
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 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. |
|
@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. |
|
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 GitHub<#897 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AO-pPqXOd_hgXYhJP8q64q2VmlmhFWdOks5tbAo-gaJpZM4R4cMI>.
|
|
@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. |
|
@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. |
|
@thinkle Exciting to hear development on the new project! I have a few questions:
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... |
|
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. |
|
On Sun, Mar 4, 2018 at 1:08 PM, Jesse Johnson ***@***.***> 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
<#897 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAi8W2-tvHdF51YHa040dHyGyco49-t6ks5tbC2UgaJpZM4R4cMI>
.
|
|
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. |
|
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 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 :) |
|
I would like to help to develop in python 2 for thus project :) |
|
@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: |
|
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. <flame_proof_suit_on> 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 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! </flame_proof_suit_on> Gourmet Maintenance 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
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: Usage: Or to clean the new lines you've commited since the last commit: Next Steps |
|
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. |
|
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. |
|
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?) |
|
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 ***@***.***> 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
<#897 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAELYWY4WBGUK7IU3GJCC5TRUJ6PLANCNFSM4EPBYMEA>
.
|
|
@thinkle - thanks for the heads-up. Does it mean that the current Python-based version is planned to be phased out at some point? |
|
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 ***@***.***> 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
<#897 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAELYW7LQN37JNWDJJGBSX3RUK44ZANCNFSM4EPBYMEA>
.
|
It is clear the gourmet repo has fallen into disrepair.
HEAD of
masterhas 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:
masterback in working condition. Consider moving the incomplete work since0.17.4to a working branch and reverting those commits onmaster. (Thanks @thinkle for fixing this!)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!
The text was updated successfully, but these errors were encountered: