What is the recommended practice in django to execute external scripts?
I'm planning to build a WebApp that will need to execute scripts based on the argument that an user will provide in a text-field or in the Url.
possible solutions that I have found:
create a lib directory in the root directory of the project, and put the scripts there, and import it from views.
using subprocess module to directly run the scripts in the following way:
subprocess.call(['python', 'somescript.py', argument_1,...])
argument_1: should be what an end user provides.
python
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
asked Jan 3 at 14:39
ArximedeArximede
418
add a comment |
I'm planning to build a WebApp that will need to execute scripts based on the argument that an user will provide in a text-field or in the Url.
possible solutions that I have found:
create a lib directory in the root directory of the project, and put the scripts there, and import it from views.
using subprocess module to directly run the scripts in the following way:
subprocess.call(['python', 'somescript.py', argument_1,...])
argument_1: should be what an end user provides.
python
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
asked Jan 3 at 14:39
ArximedeArximede
418
The second approach leaves you at the mercy of whatever the default python interpreter on the executing machine is. Say you wrote code for python3 and the server has python2.7 set as default, your scripts will all fail in very interesting ways.
– BoboDarph
Jan 3 at 14:44
removed irrelevant "django" and "drf" tags.
– bruno desthuilliers
Jan 3 at 14:55
add a comment |
I'm planning to build a WebApp that will need to execute scripts based on the argument that an user will provide in a text-field or in the Url.
possible solutions that I have found:
create a lib directory in the root directory of the project, and put the scripts there, and import it from views.
using subprocess module to directly run the scripts in the following way:
subprocess.call(['python', 'somescript.py', argument_1,...])
argument_1: should be what an end user provides.
python
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
asked Jan 3 at 14:39
ArximedeArximede
418
I'm planning to build a WebApp that will need to execute scripts based on the argument that an user will provide in a text-field or in the Url.
possible solutions that I have found:
create a lib directory in the root directory of the project, and put the scripts there, and import it from views.
using subprocess module to directly run the scripts in the following way:
subprocess.call(['python', 'somescript.py', argument_1,...])
argument_1: should be what an end user provides.
python
python
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
asked Jan 3 at 14:39
ArximedeArximede
418
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
asked Jan 3 at 14:39
ArximedeArximede
418
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
edited Jan 3 at 14:55
bruno desthuilliers
51.7k54465
51.7k54465
asked Jan 3 at 14:39
ArximedeArximede
418
asked Jan 3 at 14:39
ArximedeArximede
418
asked Jan 3 at 14:39
ArximedeArximede
418
418
The second approach leaves you at the mercy of whatever the default python interpreter on the executing machine is. Say you wrote code for python3 and the server has python2.7 set as default, your scripts will all fail in very interesting ways.
– BoboDarph
Jan 3 at 14:44
removed irrelevant "django" and "drf" tags.
– bruno desthuilliers
Jan 3 at 14:55
add a comment |
The second approach leaves you at the mercy of whatever the default python interpreter on the executing machine is. Say you wrote code for python3 and the server has python2.7 set as default, your scripts will all fail in very interesting ways.
– BoboDarph
Jan 3 at 14:44
removed irrelevant "django" and "drf" tags.
– bruno desthuilliers
Jan 3 at 14:55
The second approach leaves you at the mercy of whatever the default python interpreter on the executing machine is. Say you wrote code for python3 and the server has python2.7 set as default, your scripts will all fail in very interesting ways.
– BoboDarph
Jan 3 at 14:44
The second approach leaves you at the mercy of whatever the default python interpreter on the executing machine is. Say you wrote code for python3 and the server has python2.7 set as default, your scripts will all fail in very interesting ways.
– BoboDarph
Jan 3 at 14:44
removed irrelevant "django" and "drf" tags.
– bruno desthuilliers
Jan 3 at 14:55
removed irrelevant "django" and "drf" tags.
– bruno desthuilliers
Jan 3 at 14:55
add a comment |
2 Answers
2
active
oldest
votes
I'm planning to build a WebApp that will need to execute scripts
Why should it "execute scripts" ? Turn your "scripts" into proper modules, import the relevant functions and call them. The fact that Python can be used as a "scripting language" doesn't mean it's not a proper programming language.
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
add a comment |
Approach (1) should be the default approach. Never subprocess unless you absolutely have to.
Disadvantages of subprocessing:
- Depends on the underlying OS and in your case Python (i.e. is
pythoncommand the same as the Python that runs the original script?). - Potentially harder to make safe.
- Harder to pass values, return results and report errors.
- Eats more memory and cpu (a side effect is that you can utilize all cpu cores but since you are writing a web app it is likely you do that anyway).
- Generally harder to code and maintain.
Advantages of subprocessing:
- Isolates the runtime. This is useful if for example scripts are uploaded by users. You don't want them to mess with your application.
- Related to 1: potentially easier to dynamically add scripts. Not that you should do that anyway. Also becomes harder when you have more then 1 server and you need to synchronize them.
- Well, you can run non-python code that way. But it doesn't apply to your case.
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54024431%2fwhat-is-the-recommended-practice-in-django-to-execute-external-scripts%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I'm planning to build a WebApp that will need to execute scripts
Why should it "execute scripts" ? Turn your "scripts" into proper modules, import the relevant functions and call them. The fact that Python can be used as a "scripting language" doesn't mean it's not a proper programming language.
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
add a comment |
I'm planning to build a WebApp that will need to execute scripts
Why should it "execute scripts" ? Turn your "scripts" into proper modules, import the relevant functions and call them. The fact that Python can be used as a "scripting language" doesn't mean it's not a proper programming language.
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
add a comment |
I'm planning to build a WebApp that will need to execute scripts
Why should it "execute scripts" ? Turn your "scripts" into proper modules, import the relevant functions and call them. The fact that Python can be used as a "scripting language" doesn't mean it's not a proper programming language.
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
I'm planning to build a WebApp that will need to execute scripts
Why should it "execute scripts" ? Turn your "scripts" into proper modules, import the relevant functions and call them. The fact that Python can be used as a "scripting language" doesn't mean it's not a proper programming language.
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
answered Jan 3 at 14:54
bruno desthuilliersbruno desthuilliers
51.7k54465
51.7k54465
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
add a comment |
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
yes I think that's what I'm going to do, Is that a standard practice in django?
– Arximede
Jan 3 at 15:04
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
Also, do you have some tips on organizing the modules? should I have one folder, and all my modules go there?
– Arximede
Jan 3 at 15:06
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
The "standard practice" in django is to use Python standard practices - Django is a python framework, so it's just python code in the end. And "how to organize your modules" is way too broad a question - it really depends on what your code is doing. The only hints are the usual "high cohesion / low coupling".
– bruno desthuilliers
Jan 3 at 15:13
add a comment |
Approach (1) should be the default approach. Never subprocess unless you absolutely have to.
Disadvantages of subprocessing:
- Depends on the underlying OS and in your case Python (i.e. is
pythoncommand the same as the Python that runs the original script?). - Potentially harder to make safe.
- Harder to pass values, return results and report errors.
- Eats more memory and cpu (a side effect is that you can utilize all cpu cores but since you are writing a web app it is likely you do that anyway).
- Generally harder to code and maintain.
Advantages of subprocessing:
- Isolates the runtime. This is useful if for example scripts are uploaded by users. You don't want them to mess with your application.
- Related to 1: potentially easier to dynamically add scripts. Not that you should do that anyway. Also becomes harder when you have more then 1 server and you need to synchronize them.
- Well, you can run non-python code that way. But it doesn't apply to your case.
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
add a comment |
Approach (1) should be the default approach. Never subprocess unless you absolutely have to.
Disadvantages of subprocessing:
- Depends on the underlying OS and in your case Python (i.e. is
pythoncommand the same as the Python that runs the original script?). - Potentially harder to make safe.
- Harder to pass values, return results and report errors.
- Eats more memory and cpu (a side effect is that you can utilize all cpu cores but since you are writing a web app it is likely you do that anyway).
- Generally harder to code and maintain.
Advantages of subprocessing:
- Isolates the runtime. This is useful if for example scripts are uploaded by users. You don't want them to mess with your application.
- Related to 1: potentially easier to dynamically add scripts. Not that you should do that anyway. Also becomes harder when you have more then 1 server and you need to synchronize them.
- Well, you can run non-python code that way. But it doesn't apply to your case.
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
add a comment |
Approach (1) should be the default approach. Never subprocess unless you absolutely have to.
Disadvantages of subprocessing:
- Depends on the underlying OS and in your case Python (i.e. is
pythoncommand the same as the Python that runs the original script?). - Potentially harder to make safe.
- Harder to pass values, return results and report errors.
- Eats more memory and cpu (a side effect is that you can utilize all cpu cores but since you are writing a web app it is likely you do that anyway).
- Generally harder to code and maintain.
Advantages of subprocessing:
- Isolates the runtime. This is useful if for example scripts are uploaded by users. You don't want them to mess with your application.
- Related to 1: potentially easier to dynamically add scripts. Not that you should do that anyway. Also becomes harder when you have more then 1 server and you need to synchronize them.
- Well, you can run non-python code that way. But it doesn't apply to your case.
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
Approach (1) should be the default approach. Never subprocess unless you absolutely have to.
Disadvantages of subprocessing:
- Depends on the underlying OS and in your case Python (i.e. is
pythoncommand the same as the Python that runs the original script?). - Potentially harder to make safe.
- Harder to pass values, return results and report errors.
- Eats more memory and cpu (a side effect is that you can utilize all cpu cores but since you are writing a web app it is likely you do that anyway).
- Generally harder to code and maintain.
Advantages of subprocessing:
- Isolates the runtime. This is useful if for example scripts are uploaded by users. You don't want them to mess with your application.
- Related to 1: potentially easier to dynamically add scripts. Not that you should do that anyway. Also becomes harder when you have more then 1 server and you need to synchronize them.
- Well, you can run non-python code that way. But it doesn't apply to your case.
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
edited Jan 3 at 15:16
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
answered Jan 3 at 14:56
freakishfreakish
39.8k695139
39.8k695139
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54024431%2fwhat-is-the-recommended-practice-in-django-to-execute-external-scripts%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The second approach leaves you at the mercy of whatever the default python interpreter on the executing machine is. Say you wrote code for python3 and the server has python2.7 set as default, your scripts will all fail in very interesting ways.
– BoboDarph
Jan 3 at 14:44
removed irrelevant "django" and "drf" tags.
– bruno desthuilliers
Jan 3 at 14:55