Start Gunicorn on boot

[Nonverbis M]

*Ubuntu 16.04.3 Desktop version.*

*gunicorn (version 19.7.1)*

*virtualenv 15.1.0*


I'd like Gunicorn to start on boot. Gunicorn is integrated with *Django*.


*/etc/init/photoarchive.conf*


description "Gunicorn server for photoarchive"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
setuid server
setgid server
chdir /home/server/photoarchive/photoarchive

exec /home/server/photoarchive/venv/photoarchive/bin/gunicorn photoarchive.wsgi


What is done for self-check:

1. 

   1. 
   
   cd /home/server/photoarchive/photoarchive ls
   
I can see manage.py.

   1. 
   
   
   2. 
   
   2.
   3. 
   
   cd /home/server/photoarchive/venv/photoarchive/bin/ I can see gunicorn 
   file.
   4. 
   
   cd /var/log/upstart
   
It is empty.

   1. 
   
   
   2. 
   
   3. 
   3. 
   
   $ ps aux | grep gunicorn
   
   server 2715 0.0 0.0 21292 948 pts/6 S+ 10:12 0:00 grep --color=auto 
   gunicorn
   
Well, this is grep has grepped itself.


4. 

   1. 
   
   Activate virtualenv.
   
   cd /home/server/photoarchive/photoarchive gunicorn photoarchive.wsgi
   
Now gunicorn is running. So, manually it starts.

*Could you help me organize running gunicorn on start?*

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e021369b-9846-4daf-906d-246d52b2dbbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Start Gunicorn on boot

[Nonverbis M]

Antonis, thank you.
Yes, this is upstart. I'll try it with systemd as you suggested.

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c8308c91-bce1-4bb0-9cdb-16ce326d4e13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Discussing the documentation on formset.get_form_kwargs()

[Nonverbis M]

https://docs.djangoproject.com/en/1.10/topics/forms/formsets/#passing-custom-parameters-to-formset-forms

In the documentation there is a sentence "The formset base class provides a 
get_form_kwargs method." 

Could you help me understand why this sentence should be illustrated with 
the exmple of redefinition of this method.

Then I would say this is an example of side effect in programming: it gives 
unpredictable result. If the form is called get_form_kwargs, then we expect 
that it returns what kwargs are present in the form. But this method 
disfigures the picture.
Well, side effect in its classical meaning (
https://en.wikipedia.org/wiki/Side_effect_(computer_science))

Wouldn't just formset.get_form_kwargs(0)  be better here?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/05d9ba91-918e-483d-8c14-453a514dfece%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Formset: Is get_form_kwargs() has a bad example in documentation?

[Nonverbis M]

https://docs.djangoproject.com/en/1.10/topics/forms/formsets/#passing-custom-parameters-to-formset-forms

In the documentation we can read: 

Quotation=

The form_kwargs may also depend on the specific form instance. The formset 
base class provides aget_form_kwargs method. The method takes a single 
argument - the index of the form in the formset. The index is None for the 
empty_form 
:

>>> from django.forms import BaseFormSet>>> from django.forms import 
>>> formset_factory
>>> class BaseArticleFormSet(BaseFormSet):... def get_form_kwargs(self, 
>>> index):... kwargs = super(BaseArticleFormSet, 
>>> self).get_form_kwargs(index)... kwargs['custom_kwarg'] = index...   
>>>   return kwargs

Quotation=

I can see that 

1) Example doesn't illustrate the text of documentation. It illustrates 
redefinition of the method.

2) The example seems to be bad itself. Doesn't this brings about some side 
effect? 

https://en.wikipedia.org/wiki/Side_effect_(computer_science)


Wouldn't just *kwargs = formset.get_form_kwargs(0)* be better?

If this makes sense, I could create a ticket at Djangoproject. 

But I'm too green for deep understanding this example. So, I decided to discuss 
it here.




-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/16cf8cc0-de4a-47e5-99bc-66322d0d3066%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Update FileField: what is the name of the old file

[Nonverbis M]

*Django 1.11*

When FileUpdate is called, I substitute the old file with a new one. I'd 
like to handle the old file. Namely move it to some other directory.


Could you have a look at the picture below. New file is called "C book 
1.pdf". Existing file is called 
"4_Oracle_Database_11g_PLSQL_Fundamentals_PLSQL.pdf".



But at the breakpoint (see comment in form_valid), old_file_name = C book 
1.pdf.

But I can't catch why. I call super(FileUpdate, self).form_valid(form) in a 
couple of lines. And only there self.object = form.save().


At the breakpoint I expect self.object to be the unchanged object. Existing 
one.


*Could you help me understand how to catch the file name of the old file.*



class UserFile(models.Model):
uuid = models.UUIDField(primary_key=False, default=uuid.uuid4,
editable=False)
user_file = models.FileField(verbose_name=_("file"),
 max_length=255,
 upload_to=get_file_path)
class FileUpdate(UpdateView):
model = UserFile
form_class = FileForm

def form_valid(self, form):
"""
Delete old file.
"""
parent_directory = get_parent_directory_of_file(self.object)
old_file_name = self.object.user_file.name # Breakpoint
self.object.user_file.delete()
return super(FileUpdate, self).form_valid(form)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/36d54c66-270b-4ca5-beda-76c7f9865caf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

SelectDateWidget when DateField is not required

[Nonverbis M]

*Django 1.11.2*

I'd like to use SelectDateWidget.


class FrameDate(models.Model):
through_date = models.DateField(null=True,
blank=True,
verbose_name=_("through"))
...

class FrameDateForm(ModelForm):

def clean_through_date(self):
pass # Breakpoint

class Meta:
model = FrameDate
exclude = []

years = range(1800, datetime.datetime.now().year + 1)

widgets = {
'frame': forms.HiddenInput(),
'from_date': forms.SelectDateWidget(years=years),
'through_date': forms.SelectDateWidget(years=years)
}



As we can see, this DateField is not required. And have an empty choice at 
the top of the list ("---").

The problem is that when a user inputs only a month we'll get ValueError 
springing out to the user in case of Debug=True.

There is that method clean_through_date and the break point in it. But in 
case of incomplete set of month, day and year the program will not even 
call this clean_through_date() method. This method is called in two cases:

1) if the through_date is completely empty.

2) if it is completely filled.

If it is partially filled, form validation is ignored completely. The 
program explodes at CreateView.

*Could you comment on it? And give me a kick here: how to warn the user 
that s/he must either fill month, day and year or don't touch the 
through_date at all.*

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/24eabfb2-fe89-48a7-bce9-9bd7f6aa849b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.