I am currently working on a project that has django 1.8 installed, but the earlier team did some custom changes in the package as per requirement few years back and now we need to identify what changes were done as the earlier team members are no longer working in the company and there is no documentation as well related to what changes were done.
I tried to compare it with django 1.8, but there are no changes found. Is there any tool that can help in identifying the changes within the package.
I have tried WinMerge and git compare already, but to no avail.
Adding Repo for reference: package-compare
`swg/packages`: prod packages that has customization
`venv/packages`: my local env packages
Thanks in advance..
Related
How to make Mezzanine 4.3 work with django 3 on AZURE without issues
l've made a mezzanine blog and i'm facing challenges deploying it in AZURE cloud. Everything goes well but, when bind the blog with Engine X it requires me to Update Django for static files (css, js, images to show). When i update django I have the worst problems. It needs me to change lots of file settings some of which i dont even understand. May someone help me if there is a way to Deploy Mezzanine 4.3 and any version of Django without such challenges. It seems building was better than deployment Now.
I will be glad to be help in simple steps possible for this to work.
Thank you very much in advance
Mezzanine doesn't run on Django 3 yet. Actually, the community is trying to make it support Django 2.2. As far as Mezzanine is concerned, you're stuck with Django 2 still. The original maintainer has stopped working on the project for a long time and the community is trying to find a way forward for the project. If I was you, I wouldn't start a new project on Mezzanine. Its future is very uncertain.
I know it sounds like a dumb question and I myself felt terribly bad when I faced this unforgivable lack of knowledge about a framework that I use basically every day...but so it is!
I had the necessity of forking a django package to add some fields to some of its models. Everything fine, I forked the project on github, cloned locally and then realized that: any django package does not include a common django setup so how am I supposed to run the migrations I need in order to complete my changes and push back to the repo the new version of the app?
I thought of course of starting another django project and cloning the fork as an app but doesn't that feel a bit over the top for a process like this? What would be the correct way of doing this?
Your app ships without any project environment, but in development you need a project environment. Be it for making migrations, running tests, running the server or running checks.
Creating a django project is the way to go. Unless you decide to write migrations yourself and discard tests.
I guess django apps repositories to not provide a django project environment because it's up to the developer to configure it.
I have started Sitecore learning few months ago.That time first question come in my mind is that how can I develop module? but can not able to find documentation. Can anybody provide me documentation how can I develop custom module?
If you mean you would like to create a module for the Sitecore marketplace, as others have done, then the process is fairly simple.
Write your code (ASCX, ASPX, CS, JS, etc.)
Create your Sitecore items (Layouts, renderings/sublayouts, custom buttons, etc.)
Create your configuration files (if necessary) for the App_Config\Include folder.
Build your solution and test it in a Sitecore instance locally.
Package the published files and item together using the Sitecore packaging utility.
Contribute your module on the marketplace and upload the package for review.
What you are hoping to achieve here is that another person could grab your package, install it on their system, and be able to use it without needing to recompile your source code.
If you want to develop a module, come up with the idea and then build it.
You can then submit it to the Sitecore a Marketplace under the contribute section.
https://marketplace.sitecore.net/Contribute.aspx?sc_lang=en
Typically you'll submit a package to this section and documentation on how to setup and use the module.
Sitecore will then test the module and inform you whether it is suitable for the marketplace. Your module will then be published on the marketplace ready for others to download.
When developing your module you should consider compatibility with Sitecore versions, and you should also test it thoroughly.
Here's some more info on best practices when building modules:
https://kb.sitecore.net/articles/831724
I have a requirement where I need to develop a Point of Sale system.
I want to know if it is possible to install that small point of sale app
on some machine without source code ?
Thanks for all suggestions.
I just thought I'd mention this for anybody that finds this question useful in the future.
There was a discussion about turning a Django webapp into a local app here:
https://groups.google.com/forum/#!topic/django-users/-VGqvHew35g
They provide some interesting solutions for converting the webapp into a local/desktop app.
Django is a web framework. There's no need to install any code on a client machine, since you would access it via a web browser.
I am new to Django.
I have some doubts about installing 3rd party Apps in Django.
A specific example. The "django-registration" App in https://bitbucket.org/ubernostrum/django-registration/src. Reading the instructions the doc tell us to install this app with PIP(pip install django-registration), doing this the App will be installed in Python Site-packages, right?
My question is: The App must to be installed in that way? Why not put the 'django-registration' folder in our Project as an App?
PS: This is a starter Django Question.
Best Regards,
The App must to be installed in that way?
No.
As long as python can find it (ie: it's on the PYTHONPATH) you can put it any place you like.
Why not put the 'django-registration' folder in our Project as an App?
Why not indeed? If you plan on modifying it substantially that's perhaps quite reasonable. If you aren't, then keeping it separate will keep it plain as to what is your code and what is not; and ease the updates to either.